Discussions

News: JSR 168 Portlet API Specification Released to Public Review

Bookmark and Share Get thread feed

  1. JSR 168 Portlet API Specification Released to Public Review (25 messages)

    The JCP has released JSR 168: Portlet API Specification for public review. This spec is the standard for supporting Java portlets inside of portal servers and allows developers who want to be able to develop portlets on several different vendors' portal servers, much like J2EE web applications run inside any brand of application server.

    JSR 168: Portlet API Detail Page

    Download JSR 168 Public Review Spec

    The public review closes on 16 August 2003

    Sun has also come out with a beta of Sun ONE Studio Portlet Builder.

    Read article: Sun Goes Public With JSR 168, Beta Of New Portlet Builder


    Which developers here are building applications on portals now (BEA, WebSphere, Jetspeed, Oracle, etc.), and what do you think of this specification?
    Reply to this

    Threaded Messages (25)

  2. Liferay Enterprise Portal[ Go to top ]

    Good to see JSR 168 up for public review. Liferay is an open source portal solution that will be supporting this. See http://www.liferay.com for our site and http://my.liferay.com for the demo.
    Reply to this Reply to original

  3. Question about Portal/Portlets[ Go to top ]

    As we all know there are a lot of View (JSP, XMLC, Velocity, WebMacro, etc.) and Framework (Barracuda, Struts, WebWork, etc.) technologies for server side presentation layer.

    My question:
    Is that posible to mix the view + framework within one portal? So, let's say I have a portal product installed, which supports JSR 168. For my portal I create some portlets, also based on JSR 168 (one in XMLC+Barracuda, one in JSP+Struts, one in Velocity+pure servlet, etc.). Can I just mix those portlets in my portal without problem? Or we will use Portlets instead of all those Frameworks (= View + Portlet instead of View + Framework)?

    Thanx!
    Lofi.
    http://www.openuss.org
    Reply to this Reply to original

  4. jportlet[ Go to top ]

    does anyone know how liveray stacks up against jportlet
    Reply to this Reply to original

  5. jportlet[ Go to top ]

    basically I think jportlet is the better product, because its more based on portlets, and it will not take long for it to adapt to the new portlet api. The only problem I have with it is that the cvs is broken for more than a month now. I emailed the projectlead about it, but he basically ignored it.
    -chris
    Reply to this Reply to original

  6. Question about Portal/Portlets[ Go to top ]

    As we all know there are a lot of View (JSP, XMLC, Velocity, WebMacro, etc.) and Framework (Barracuda, Struts, WebWork, etc.) technologies for server side presentation layer.

    >
    > My question:
    > Is that posible to mix the view + framework within one portal? So, let's say I have a portal product installed, which supports JSR 168. For my portal I create some portlets, also based on JSR 168 (one in XMLC+Barracuda, one in JSP+Struts, one in Velocity+pure servlet, etc.). Can I just mix those portlets in my portal without problem? Or we will use Portlets instead of all those Frameworks (= View + Portlet instead of View + Framework)?

    As long as all of your view technologies implement the Portlet API, you can indeed use different technologies to create the response for each portlet. In the short term, there is also a provision for portlets to use RequestDispatcher.include() so that they can "import" content from existing servlets and JSP pages.

    Longer term, I think you will see view technologies like the ones you mentioned provide specific support for being accessed via the portlet API. This is definitely on my list of enhancements for Struts, and it's already going to be possible to use JavaServer Faces in a portlet (the EA4 release abstracted away the differences between servlet and portlet APIs), so it's easy for portal server vendors to support that as well.

    >
    > Thanx!
    > Lofi.
    > http://www.openuss.org

    Craig McClanahan
    Reply to this Reply to original

  7. Question about Portal/Portlets[ Go to top ]

    <quote>
    As long as all of your view technologies implement the Portlet API, you can indeed use different technologies to create the response for each portlet.
    </quote>

    this would be great. At the end you can deliver a real "component" with:
    - a view (in this case a portlet), which can be written in different technologies (JSF, JSP, XMLC, Velocity, Barracuda, Struts, WebWork, etc.).
    - business interfaces which consist pure Java interfaces.
    - business implementations which implement the business interfaces. Here you can also choose your implementation technologies (combination of POJO, SSB, EB, Hibernate, etc.).

    And this component can be installed in any J2EE portal products, not bad!

    Nowadays, it's already possible to use different kind of business implementations mixed within one component in standard way. The problem is the view. You surely can mixed the view's technologies (some JSPs, some XMLC) but you need to use a same framework (only struts, only Barracuda). If you try to mix different frameworks you'll be "crazy" because there is no standard way for this. Or anyone has tried this?

    Lofi.
    http://www.openuss.org
    Reply to this Reply to original

  8. Java portlets[ Go to top ]

    Open source projects

    http://jportlet.sourceforge.net/
    http://jakarta.apache.org/jetspeed/site/index.html
    http://www.liferay.com/home/index.jsp
    http://basicportal.com/
    http://www.jahia.org/
    http://jporta.sourceforge.net/

    Commercial products

    BEA WebLogic Portal - http://edocs.bea.com/wlp/docs81/javadoc/com/bea/portal/model/Portlet.html

    IBM Websphere Portal - http://www.software.ibm.com/wsdd/zones/portal/

    Oracle Portal Developer Kit - http://portalstudio.oracle.com/


    See also:

    PSML - http://jakarta.apache.org/jetspeed/site/psml.html
    Reply to this Reply to original

  9. Java portlets[ Go to top ]

    Just to clarify, Jahia is not open-source.
    Reply to this Reply to original

  10. Re: Java portlets[ Go to top ]

    No, Jahia is not 100% OSI compliant. Jahia is released under a collaborative source license (contribute or pay paradigm). So you may consider this as a kind of viral effect on contributions ;-). Whether you contribute directly (and then you may use it for free as any other open source project), whether you pay some license fee for your production servers in order to indirectly sponsorize future enhancements.
    You may note that the full source code is available for free for research and development purpose (cvs.jahia.org).
    Another nice thing in Jahia is the fact that you can use standard servlets directly as portlets (without any kind of PSML, custom portlet.xml file,...) and that it integrates a full CMS server.

    Stéphane
    Reply to this Reply to original

  11. Jetspeed 2.0 - the reference implementation[ Go to top ]

    I think Jetspeed from Apache Jakarta is suppose to be the reference implementation. More specifically, Jetspeed 2.0, which has been under development for several months. The developers will be ready to commit Jetspeed-2 to a new branch under the jetspeed cvs in apache soon. I have followed this project since version 1.2. The current version is 1.4b4. The work that Dave Blackett, Kevin A. Burton, Santiago Gala, Glenn Golden, Raphaël Luta, Mark Orciuch, Ingo Schuster, Paul Spencer, David S. Taylor, Jason Van Zyl, and Scott Weaver has been paramount to the portal and portlet framework. Jetspeed 2.0 will be very interesting to see.
    Reply to this Reply to original

  12. Re: Jetspeed 2.0 - the reference implementation[ Go to top ]

    While they clearly sperate the implementation of the new Portlet container (JSR 168) from the specific Jetspeed Portal. No Problem. Perhaps the project is even more close to Tomcat than to Jetspeed...

    cf The Apache IBM proposals:
    http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal
    http://nagoya.apache.org/wiki/apachewiki.cgi?CharonProposal

    Stéphane
    Reply to this Reply to original

  13. Jetspeed 2 (Struts, Pluto and the whole ball of wax)[ Go to top ]

    Jetspeed 2's core container, as it stands now, is Pluto. We are currently in the process of working out the specifics of releasing Pluto along with Jetspeed 2. We have been working closely with IBM's portal group that is working on Pluto, so we should have some pretty kewl inter-project harmony going on in the future. So I want to give a shout out to Stefan Hepper from IBM who has been a big help when it comes to Pluto and the JSR in general.

    I also want to make it VERY clear we are more than happy to work with other framework projects to make integration of frameworks like Struts, Tapestry and Turbine as easy and robust as possible.

    Craig,

    As much direction as you can give us on Struts the better. Join the jetspeed-dev list if you are interested in drawing up some proposals.

    -scott
    Reply to this Reply to original

  14. Re: Jetspeed 2 (Struts, Pluto and the whole ball of wax)[ Go to top ]

    Why aren't such discussions run on the normal jetspeed dev-list? There is a little bit too much secrecy around the implementation and how these things will work out - a bit too many things are going about in the background with the JSR 168. And what about Pluto? It isn't exactly, so far, developed in an Open Source fashion?

    - The JCP, and especially the JSR 168, aren't exactly too open processes in my opinion.
    Reply to this Reply to original

  15. Re: Jetspeed 2 (Struts, Pluto and the whole ball of wax)[ Go to top ]

    Why aren't such discussions run on the normal jetspeed dev-list? There is a

    > little bit too much secrecy around the implementation and how these things will
    > work out - a bit too many things are going about in the background with the JSR
    > 168. And what about Pluto? It isn't exactly, so far, developed in an Open Source
    > fashion?

    Actually, they have started in Jetspeed dev as of Friday (07/18). We (Jetspeed developers) have been under NDA. Since the JSR-168 is in public review, we can now speak freely. Beleive me, it has been excruciatingly painful to keep our mouth's shut, and it hasn't felt much like open source because of that. That's in the past now, discussions on J2 is happening on both the user and the dev lists.

    As for Pluto, we were told that it would eventually be released under a an Apache/BSD style license. We are still waiting confirmation of that as there are still concerns on were Pluto wil "live" as a project.

    -scott
    Reply to this Reply to original

  16. Jetspeed 2 (Spring)[ Go to top ]

    ´[...]

    > I also want to make it VERY clear we are more than happy to work with other framework projects to make integration of frameworks like Struts, Tapestry and Turbine as easy and robust as possible.
    >
    > Craig,
    >
    > As much direction as you can give us on Struts the better. Join the jetspeed-dev list if you are interested in drawing up some proposals.
    >
    > -scott

    How would the recently released Spring framework fit into this picture? Maybe an integration with Jetspeed/Pluto could help Spring gaining popularity. Juergen Hoeller, Rod Johnson what do you think?

    Valentin Richter

    Raytion GmbH
    Düsseldorf
    Reply to this Reply to original

  17. Jetspeed 2 (Spring)[ Go to top ]

    How would the recently released Spring framework fit into this picture? Maybe an integration with Jetspeed/Pluto could help Spring gaining popularity. Juergen Hoeller, Rod Johnson what do you think?


    I consider this a very interesting suggestion! Actually, I've been thinking about this for quite a while, since I've had my first look at a Portlet spec draft in the JetSpeed CVS some months ago. Now that the spec is officially released and JetSpeed 2 is on its way, we might try some concrete integration.

    We're currently busy working towards 1.0 though, tuning the framework both in terms of API and implementation. So Portlets don't have a high priority at the moment, but they are definitely on my list. Of course we'd welcome respective contributions - any volunteers for a Spring/JetSpeed integration? :-)

    Juergen
    Reply to this Reply to original

  18. Jetspeed 2 (Spring)[ Go to top ]

    [...]

    > We're currently busy working towards 1.0 though, tuning the framework both in terms of API and implementation. So Portlets don't have a high priority at the moment, but they are definitely on my list. Of course we'd welcome respective contributions - any volunteers for a Spring/JetSpeed integration? :-)

    We have a proof-of-concept project starting in September. One of its requirements ask for a portlet based on JSR168. If the Spring framework is mature enough we could use Spring as the underlying framework and use the project to test the waters for a Spring/Portlet/Jetspeed integration. We'll check the status of the Spring framework early September and see what's possible. :-)

    Does anybody know about the timeline for the release of the final version of the portlet specification and the availability of Pluto/Jetspeed 2?

    Valentin Richter

    Raytion GmbH
    Duesseldorf
    Reply to this Reply to original

  19. JSR 168 Portlet API Specification Released to Public Review[ Go to top ]

    Can somebody point me to the section of the spec that shows how to access portal container services in a generic way. They seem to have done some of this with profile management (USER_INFO) but not content management.

    It looks like I could write a portlet that could sniff the state of other portlets since scoping is controlled through namespaces (javax.portlet) only.
    Reply to this Reply to original

  20. Finally![ Go to top ]

    Great to see this in public review. Finally.

    We will be replacing our own portlet API (based on the IBM WPS 4.1 API) with this ASAP. The current API looks good, with decent loopholes for doing interesting things, and with some interesting places for future enhancements (I'm personally missing portlet *instance* lifecycle methods). I'm personally going to make sure that WebWork2 works well with portlets.

    It'll be interesting to see whether the goal of web components finally can be achieved. I sure hope so.
    Reply to this Reply to original

  21. JSR 168 Portlet API Specification Released to Public Review[ Go to top ]

    We developed two portals using Jetspeed 1.4:

    http://www.anglonaweb.it
    http://www.gruppoatlantis.com

    Overall impression of the Jetspeed API was quite good, but the lack of standards complicated our work a lot... we think the release of the spec is a good news for sure. Jetspeed's Turbine framework dependence (instead of Struts, more J2EE oriented) was another obstacle.

    We evaluated also IBM and Oracle's solutions; they're both very good. I think people working on Jetspeed 2.0 still have a lot of work to do...

    F.Gianneschi
    Atlantis S.p.A.
    Reply to this Reply to original

  22. "FLOAT" WindowState would be nice[ Go to top ]

    I think they should include a "FLOAT" WindowState along with NORMAL, MAXIMIZED and MINIMIZED. Even if you are able to define custom WindowStates, floating a window is commonplace in many portals and portlets developers would benefit by knowing that this state is supported out of the box by the portlet container.
    Reply to this Reply to original

  23. RE: "FLOAT" WindowState would be nice[ Go to top ]

    <troll mode>
    Why use a window for float when the CSS2 standard contains float and visibility properties? I.E. (pun intended) you can('t) simulate a floating window...

    Vote now - make links (javascript or regular) that open new windows illegal. As it's just a dumb feature used by ignorant developers, as most decent browsers allow you to make those pesky new windows that gives you a headache appear in a new tab anyway...!
    Reply to this Reply to original

  24. FLOAT WindowState != Popup Window[ Go to top ]

    FLOAT WindowState != Popup Window

    FLOAT WindowState allows the user to display a portlet in a different window, when he chooses to do so!!! This window is usually small, and doesn't have navigation buttons nor menus. It's very useful to display things like real-time stock quotes, instant messaging, or being notified of an answer to one of your proposals in the company bulletin board. This allows you to keep the portlet around in an unobtrusive manner (you can keep your alerts open all the time in the right upper corner of your screen as opposed to having to switch to your real state hungry portal every 5 min).
    Reply to this Reply to original

  25. RE: FLOAT WindowState != Popup Window[ Go to top ]

    Ehh, wasn't what you described a irritating "popup" - guess I must be missing something :)

    <flame>
    Popup's (or "displaying stuff in a small window without navigation controls cluttering up the screen and being basically a ...") are only used by webdevelopers who are in their infancy. Having found out about the magical hammer (dhtml) and trying desperately to use if for everything (I'm just waiting for the first time when one try to build a real house out of html code on building blocks...) or as advertising - trying to irritate people just as much as the "small information window script kids" do.
    Reply to this Reply to original

  26. Where to discuss?[ Go to top ]

    Where are some good discussion boards, newsgroups, mailing lists, etc. to find out what people's opinions are concerning JSR 168? The Jetspeed list had a brief spat of threads, but that has died down.
    Reply to this Reply to original