JSR 168 Portlet Specification Proposed Final Draft Posted


News: JSR 168 Portlet Specification Proposed Final Draft Posted

  1. The Portlet JSR 168 has been posted in Proposed Final Draft form. The Portlet spec intents to enable interoperability between Portlets and Portals by defining a set of APIs for Portal computing that addresses the areas of aggregation, personalization, presentation and security.

    Portlet Proposed Final Draft and JSR 168 Homepage.

    Related: First public review announcement and discussion.

    Threaded Messages (9)

  2. wish it could coming soon[ Go to top ]

    it's so boresome to modify the code from websphere portal to weblogic portal :P
  3. Portlets, J2EE 1.4[ Go to top ]

    Does J2EE 1.4 include Portlets?

    Will J2EE 1.4 vendors be required to implement the Portlet specification?
  4. Portlets, J2EE 1.4[ Go to top ]

    Does J2EE 1.4 include Portlets?


    > Will J2EE 1.4 vendors be required to implement the Portlet specification?

    although it's not necessary !
    however, most j2ee vendor will make the portal product ,
    for example , bea, ibm, sun, sap and etc...
  5. Is Jetspeed the Refrence impl for this spec..

    what is the relationship of Jetspeed and IBM websphere portal . Is it competative or complimentary
  6. It is not really clear to me what is the connection between IBM and jetspeed but what i can tell is that the creation of eXo is tightly nit to IBM and Jetspeed.

    This is not another advertising but an interesting story that may explain some connections...

    When i first planned to implement a portal I looked at jetspeed cvs in january. There, there was a portlet API draft that was written by Stefan Hepper from IBM.
    I read it and yes it was very well designed. So I decided to implement it as I needed a portal for my researches. After that i realised that this draft was really closed from the last Websphere portlet API.

    Moreover, when I realised that Stefan Hepper was one of the spec lead of the JSR 168 team I knew that implementing the websphere API was the way to go (it explains why we port exo portal to JSR 168 quite quick as the API are very similar).

    Last thing, when I heard that the jetspeed team had access to the drafts before it comes to public, I really wondered how free and open jetspeed could be...

    It may not explain everything but at least it can raise questions.... but I have not the answers yet.

    Is this new API just the result of IBM lobby?
    Is this the reason why it was so long to come to public?
    Is jetspeed just the "community" version of IBM websphere?

    please, I need to know.

    Nevertheless, the API is there now and very well designed as it is simple and powerfull.
  7. There is no real big news in that draft since previous release.

    To be quick there is only three new points, 9 modifications of existing functionnalities (to take an example : PortletPreferences.isModifiable has been replaced by PortletPreferences.isReadOnly...) and 16 clarifications.

    So moving eXo portal to this last draft should be quick (we still have to read once again those 140 pages).

    There is a new section that has been added and that is quite interesting : "Features Deferred to Future Releases".

    Inside that part there is the extension of the servlet filter design to portlets. As we actually work on using aspectJ to add cache and security aspects to portlets (in the coming beta 2 version) it would be quite easy to add a simple design for filters too.

    The other point is the message design that allows portlets to communicate. As we first (version 0.1) implemented the websphere api where this message design was required, it will also be quite quick to adapt to JSR even for eXo 1.0.

    Hope it gives more information of the status of this new draft.
  8. AFAIK this was not addressed Sun JCP:
    1. http://marc.theaimsgroup.com/?l=jetspeed-user&m=105850057414235&w=2 (What about client side ?)
    2. Also JetSpeed has a reputation as slow. (bP ships with a stress test tool, so should others)
    3. One can't even take a EJB from IBM to BEA, what organization is not hetrogenious with dual or mutiple platforms (C# and Java)
    Anyway, basicPortal.com will ignore 168 (for above reasons. Also today's news, Sun sales fell 20% for the Q., according to news.com)

    I do think that Portlet should be allways (and only?) used with JSF and EJB, (and only by companies that do not have any other platforms active) for quite a "situation".

    And we are getting bombarded by both sides:
    Nice, simple (see how they listen to users).
    Good, I do not want either side to win.

    And then there open source portals (will not do Sun JCP 168 either):
    PHP forums, Nukes, Zope, Plone...

    Next version of bP will be using (instead of single platform 168) this instead, so we can all live in peace, and make javascript calls via WS:

    my .2c
  9. Where can I download the reference implementation?
  10. JSR-168, reference implementation?[ Go to top ]

    As I know there is no reference implementation yet.

    IBM is working on it (called Pluto) and it is announced for september. I´ve also heared that Jetspeed 2.0 should support JSR-168 (who wonders?) but I haven´t verified this.

    So, the only Portal I know that implements JSR-168 is eXo Portal (http://sourceforge.net/projects/exo) and I think they have done a good job yet.