The Java Portlet API has been moving through the JSP process. The time has come for the vote on the community review, and people were wondering what was taking so long. The technology seems fairly straight forward so what was the problem? It appears that once again politics was the issue. When you look at the comments, you see that some companies are concerned about the TCK license.

It was still voted in.

Read the results of the community review vote

Read the JSR 168: Java Portlet API detail

At what point will a public review of this spec be made available ... I have heard about this spec for what seems like years. Does anyone have an idea ?

JSR168 and JSR170 will change the market for CMS software dramatically. There
is even a new market coming up. Certain companies want to be ready and have
their implementation done before someone outside this group can start working
on it. Just imaging there would be an open source implementation? This will
be a huge market in the near future.

What about the open sourcing of the implementations of reference? Does IBM (and the others) still want to contribute them to the Apache Foundation?

http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal
http://nagoya.apache.org/wiki/apachewiki.cgi?CharonProposal

In all the cases, the "first to market" advantage for commercial vendors inside the Expert Group will not last. Even if they do not contribute the RI, it will just be a question of months before having some other open source implementations of both standards.

Regards

Stéphane Croisier
--- www.jahia.org ----

> is even a new market coming up. Certain companies want to be ready and have
> their implementation done before someone outside this group can start working
> on it. Just imaging there would be an open source implementation? This will
> be a huge market in the near future.

Well, once they are released at least our CMS will be ready for it. The spec isn't that complicated to implement so I doubt that it will make much difference if you're first or last in implementing it; I expect most companies to have implemented it fairly shortly.

Implementing the JSR168 is fairly straight forward. I have done it based
on the initial proposal. The real challenge is to build a CMS or better
to say a CMS-server (JSR170). A Websphere or Weblogic for Portlets
supporting both JSRs and hot deployment. I know that you (sitevision)
are on the way. Since is taking sooo much time for the JCP group to release
a public draft I think that certain companies are behind their schedule.

Just my 2 cents....

Rickard,

I vaguely recall a posting you made way back on the Portlet API, where you question the need of standadising this concept. Are you still on the same track regarding this issue, i.e. against it?

Greetings from your "old" home country ;)

There are already some open source Portal projects out there which more or less implemented the Portlet API. I saw people taking the IBM websphere portlet spec's and start implemeting. More or less roughly I expect this to be the Portlet API (but who knows ;-). And yes I think the real challange will be writing cool portlets.

> question the need of standadising this concept. Are you still on the same track
> regarding this issue, i.e. against it?

I was commenting on an old proposal. The current proposal, and the accompanying API, is great. 'nuff said. It's going to be a blessing to have a decent component-standard for the web, which this has the potential to become.

/Rickard

Any idea of who will provide the reference implmentation and when? There seems to be quite a bit of confusion around this particular topic.

Also will the reference implementation show how the Portlet API can work with Java Server Faces?

Regards,

DLS.

Here are some of the Open Source Portals implementing Portlet specification or goint to implement. <BR>
Jetspeed<BR>
Liferay <BR>
jPorta <BR>

Enterprise Portals for free - A look at the Open Source java portals from javaboutique

Krishna

for Liferay its www.liferay.com
sorry for the wrong url in the previous post

http://jportlet.sourceforge.net is probably the cleanest implementation of all the opensource portlet container. It does worth a look

.. says the only member of the jportlet development team ;-)

On another note, I am still not sure about the overlap with other component-oriented approaches to web development, such as Tapestry - and JSF.

Christian

> component-oriented approaches to web development, such as Tapestry - and JSF.

As far as I can tell there is none. The Portlet API is about the container-component contract, and Tapestry and JSF are (AFAIK) about how to build the components. I'm not totally up on Tapestry, but I'd guess this is the case anyway.

This is what's so cool about portlets because (at least theoretically) it should be possible to mix portlets written in Struts, Tapestry, XWork, etc. on a single page, and I think that's really great. People can choose the approach they like for each portlet, and still be able to mix them together in a single application.

> should be possible to mix portlets written in Struts, Tapestry, XWork, etc.
> on a single page, and I think that's really great. People can choose the
> approach they like for each portlet, and still be able to mix them together
> in a single application.

I am *very* sceptical on that one. All the component-oriented approaches I know have a very definitive understanding of how the request/response circle is handled, how URIs and parameters are mapped to object/component properties, and the like. Unless the Portlet API can be established as some kind of "super-API" for all other libraries (not happening), there will be little interoperability IMO - in particular with components on the same page.

> have a very definitive understanding of how the request/response circle is
> handled, how URIs and parameters are mapped to object/component properties, and
> the like. Unless the Portlet API can be established as some kind of "super-API"
> for all other libraries (not happening), there will be little interoperability
> IMO - in particular with components on the same page.

The Portlet API does indeed define how parameters are passed on to individual portlets, so all of that stuff is handled by the spec. As it should be.

I do expect that libraries will have to be modified somewhat to support it, but overall I think it should be very possible to have components using different libraries on the same page.

> > have a very definitive understanding of how the request/response circle is
> > handled, how URIs and parameters are mapped to object/component properties, and
> > the like. Unless the Portlet API can be established as some kind of "super-API"
> > for all other libraries (not happening), there will be little interoperability
> > IMO - in particular with components on the same page.
>
> The Portlet API does indeed define how parameters are passed on to individual portlets, so all of that stuff is handled by the spec. As it should be.
>

I agree.

> I do expect that libraries will have to be modified somewhat to support it, but overall I think it should be very possible to have components using different libraries on the same page.

One of the changes we made in the EA4 release of JavaServer Faces was to abstract away the differences between the Servlet and Portlet APIs. This was deliberately done to make it easy for portal servers implementing JSR-168 to also support JavaServer Faces in their portlets.

For Struts, we are currently bound to objects like HttpServletRequest and HttpServletResponse -- that is something we will want to change in order to work nicely within portlets. It is high on my priority list for work after the 1.1 final release (coming VERY soon).

In the mean time, a JSR-168 portlet can use what amounts to a RequestDispatcher.include() call to include content from existing servlet API based environments -- so the concept of aggregation of dynamic content produced with different technologies is very real. And very cool.

Craig McClanahan

> RequestDispatcher.include() call to include content from existing servlet API
> based environments -- so the concept of aggregation of dynamic content produced
> with different technologies is very real. And very cool.

Yup. We do this all the time both with Velocity and WebWork stuff, and it's a great way to reuse servlet functionality. For customers, we encourage them to use JSP with JSTL to do functionality, and they really like that they can do JSP with JSTL snippets (typically invoking a database with the <sql> tags) and have that appear as a portlet fragment in their pages. As you said, very cool.

Can someone point out where this public review document exists? I can't seem to find it when I go here:

http://www.jcp.org/en/jsr/detail?id=168

where is it hiding?

Thanks
Jay

I am with Jay.

I was looking for its public draft, but could not find it anywhere.
Could someone point out the location of the same.

Thanks
-ShriKant

try this: http://jcp.org/aboutJava/communityprocess/review/jsr168/index.html

> should be possible to mix portlets written in Struts, Tapestry, XWork, etc.
> on a single page, and I think that's really great. People can choose the
> approach they like for each portlet, and still be able to mix them together
> in a single application.

Fantastic. Then the poor schmuck left maintaining this wonderous application has to know about Struts, Tapestry, XWork and more.

Dammit, development is the *cheap* part: it's software maintenance that costs.

Sean

> has to know about Struts, Tapestry, XWork and more.

Sure, you could do it that way, which would probably be dumb for maintenance and other reasons, but that was not the case I was thinking about.

I was thinking of the case where you'd buy/download 3rd party portlets, and instead of going "damn, they're not using Struts so it doesn't fit in my app", you go "oh here's some nice functionality that does the job and I don't care how it does it".

Thinking that you'd maintain the entirety of your own app is what you'd be trying to get away from by utilizing portlets.

If people want to have a look there is also gridsphere (which I'm involved in).

Additionally, BEA WebLogic Portal 8.1 supports a version of this specification. Although, I admit I'm not sure which version it supports at ship.

Tyler Jewell
Director, BEA