Discussions

News: Apache Pluto 1.0.1 released

  1. Apache Pluto 1.0.1 released (19 messages)

    The Apache Pluto Community has announced the first general availability release of Apache Pluto - Pluto 1.0.1. Pluto is the reference implementation of the Java Portlet Specification (JSR-168).

    Pluto 1.0.1 contains fixes for nearly all reported bugs reported against the various release candidates. It also includes support for the hot deployment of Portlets which are deployed through the Administrative portlets provided with the Portal Driver.

    Pluto 1.0.1 distributions can be accessed from http://portals.apache.org/pluto/mirrors.cgi

    Documentation can be found at the Apache Pluto web site: http://portals.apache.org/pluto/

    If you're doing portlet development, is Pluto your development environment? If not, why not?

    Threaded Messages (19)

  2. indirectly[ Go to top ]

    Indirectly pluto is our portlet container. Jetspeed 2 M3 is the portal we test against. That uses pluto as its portlet container so you could say we test against it.

    Using pluto directly is too much trouble since it really is not intended for stand alone usage (or otherwise they would have implemented a more useable way of configuring it).

    Jetspeed 2 is sort of ok though it is somewhat limited and definately a work in progress. I hope to see a M4 release soon BTW. Overall, I would recommend neither pluto nor jetspeed for any production usage.

    BTW. the whole portlet thing is somewhat of a disappointment. I think the standard is far too limited to allow for useful portlets with no other external dependencies than jsr 168 stuff. Also it seems like a really complicated way to implement something very simple. The whole container in a container notion and the associated administration bureaucracy adds more problems than it solves IMHO and besides very relevant portions of configuration are not even covered by JSR 168 (and are different from vendor to vendor).
  3. Using pluto directly is too much trouble since it really is not intended for stand alone usage (or otherwise they would have implemented a more useable way of configuring it)

    We definately realize the frustration and complexity of embedding pluto directly. The goal of Pluto 1.1 - which is a rewrite of 1.0.1 - is Simplification. We are simplifying:

    1) the container api - (and what is necessary to embed pluto)
    2) installation of the pluto portal (test driver)
    3) deployment of portlets

    Our goal is to create a much nicer user experience for both developers looking to embed pluto and for users looking to use it as a development or lightweight envrionment.

    Please check it out and let us know your feedback:

    Docs: http://portals.apache.org/pluto/1.1/index.html
    Source: http://svn.apache.org/repos/asf/portals/pluto/branches/pluto-1.1/

    Documentation is still a little sparse, but we welcome your questions on the user list. To reflect our dedication to pluto 1.1, the source code will be moving to trunk within the next week or so.

    David
  4. Re: Indirectly[ Go to top ]

    BTW. the whole portlet thing is somewhat of a disappointment. I think the standard is far too limited to allow for useful portlets with no other external dependencies than jsr 168 stuff. Also it seems like a really complicated way to implement something very simple.

    Is the granularity of a portlet too coarse you think?

    I haven't tried any of the Java component architectures (JSF, Tapestry).

    On the low end you have custom JSP tags or things like Tiles. But these are rather crude bits more for abstraction purposes, and loose fitting without some higher level framework to bind them.

    Then you get the "components" of something JSF or Tapestry. Here you get event dispatching into the object. Your components could be anything from generic sophisticated Grid/Table view all the way up to a self contained Blog "component".

    I have worked with the "User Controls" (I think that's what they're called) in ASP.NET. Here, you simply create ASP.NET pages, but you can import and use them like JSP tags, or you can even dynamically create them and insert them in to your page tree via code (MS has an elegant little "portal-esque" starter kit that leverages this -- it's quite clever). They're much like JSP tags built from JSP files (vs hand crafted java), but they gain the advantage of the ASP.NET event model for dispatch, so in that sense they're self contained and component like.

    But Portlets seems to be more heavy weight than these. You wouldn't create a Grid Control using a portlet.

    There was an article linked off of java.net yesterday (In JDJ if I recall) advocating the Portal container as a generic web app platform. But it just seems to me that the portals are too big, perhaps too cumbersome, vs one of the component technologies.

    Again, I haven't used them, nor any of the Java component technologies, but that's just my gut reaction based on what I've seen. Is that what you've found or am I off base?
  5. Re: Indirectly[ Go to top ]

    There was an article linked off of java.net yesterday (In JDJ if I recall) advocating the Portal container as a generic web app platform. But it just seems to me that the portals are too big, perhaps too cumbersome, vs one of the component technologies.Again, I haven't used them, nor any of the Java component technologies, but that's just my gut reaction based on what I've seen. Is that what you've found or am I off base?

    My guess is that the article was actually advocating the portlet container as the web app platform - not necessarily the portal. The portlet container manages the lifecycle of portlets - initialization, invocation, and destruciton - and can be quite light weight. The portal is what adds the value added services (sso, aggregation, content mgmt, etc. . .) which can be heavy weight.

    It depends what you are doing, but there are definately advantages to using a portlet container within a standard web app. If you need to provide the abililty for external vendors to be able to plugin components into your webapp, a portlet container is a great choice that can be leveraged rather easily. For instance, Apache Geronimo uses Pluto to manage the components of their web console. The vision is to allow vendors to include management portlets within their enterprise apps which can be automatically deployed to the web console.

    Pluto 1.0.1 is difficult to accomplish this with. Pluto 1.1 has been designed specifically to easily handle this type of situation without any headaches.
  6. Re: Indirectly[ Go to top ]

    My guess is that the article was actually advocating the portlet container as the web app platform - not necessarily the portal. The portlet container manages the lifecycle of portlets - initialization, invocation, and destruciton - and can be quite light weight. The portal is what adds the value added services (sso, aggregation, content mgmt, etc. . .) which can be heavy weight.

    Actually, the sso, cms, etc. were part of the advocacy.

    This is the link: http://java.sys-con.com/read/131819.htm

    No matter.

    But regarding the container, what lifecycle attributes does the portal container offer over and above the standard servlet container that makes it desirable outside of the heavier weight attributes that you mentioned?
  7. Portlets as the application[ Go to top ]

    At my day job, we are in the progress of redesigning our web application as several portlets, using Pluto as the container. The killer feature for us is layering on WSRP, allowing our portlets to be embedded by any (or multiple) WSRP-compliant portal(s).

    Previously, we had a portlet interface, but this meant we had to install our portlet into other portals along side many other portlets. With WebLogic, at least the version we are using, this meant dealing with dependency hell as all the portlets shared the same classloader.

    Using Pluto and WSRP, we can still play with the portals, but now manage our application on our end, and get a local instance to boot. Furthermore, Pluto can be customized to so completely blend our portlets, they appear as a single application to the user.
  8. re: Portlets as the application[ Go to top ]

    At my day job, we are in the progress of redesigning our web application as several portlets, using Pluto as the container. The killer feature for us is layering on WSRP, allowing our portlets to be embedded by any (or multiple) WSRP-compliant portal(s). Previously, we had a portlet interface, but this meant we had to install our portlet into other portals along side many other portlets. With WebLogic, at least the version we are using, this meant dealing with dependency hell as all the portlets shared the same classloader.Using Pluto and WSRP, we can still play with the portals, but now manage our application on our end, and get a local instance to boot. Furthermore, Pluto can be customized to so completely blend our portlets, they appear as a single application to the user.

    Cool! I would be nice if you could write up the details. If no one else wants to publish it, I'd make sure it got onto the Pluto web site.
  9. iferay[ Go to top ]

    You should give liferay a go, tried it out last night ... first impression (very high leven overview) were very good
  10. iferay[ Go to top ]

    Liferay is nice, however, I couldn't get their WSRP producer working with WebLogic. The services this exposed didn't have a title or description, causing WebLogic to choke. I posted a message about it on their forum, but with no response.
  11. indirectly[ Go to top ]

    BTW. the whole portlet thing is somewhat of a disappointment. I think the standard is far too limited to allow for useful portlets with no other external dependencies than jsr 168 stuff. Also it seems like a really complicated way to implement something very simple. The whole container in a container notion and the associated administration bureaucracy adds more problems than it solves IMHO and besides very relevant portions of configuration are not even covered by JSR 168 (and are different from vendor to vendor).

    You quote on portlets looks exaggerated to me. You should be more descriptive while quoting something like this. What exactly are the problems you felt and during what kind of development? Till now we have created hundreds of portlets and very much happy with it. In fact, for me now it has become impossible for me to think of an application development with using portlets. Recently we have implemented one B2E portals in a day for a company using our readymade portlets, which would IMHO be impossible without using portlets. We have also recently released JSR 168 compliant collaboration portlets and it simplifies lots many facet of application development, deployment and administration. Due to the portlet based architecture you can get these portlets up and running in 5 minutes in your environment. It is very difficult for a web application to adopt in your environment in 5 minutes. Isn't it?

    Punit Pandey
    http://portlets.blogspot.com
  12. indirectly[ Go to top ]

    In fact, for me now it has become impossible for me to think of an application development with using portlets.
    Typo? "with" -> "without".
    Recently we have implemented one B2E portals in a day for a company using our readymade portlets, which would IMHO be impossible without using portlets.
    Same experience here. Our average implementation time for small/medium internet/intranet/extranet websites using our ~50 readymade portlets is 1-3 days.
  13. Apache Pluto 1.0.1 released[ Go to top ]

    Yeah: Portlets + JSF + EJB

    Is this RiA?
    Or improved Java?

    .V
  14. Test[ Go to top ]

    <script>
      window.close()
    </script>
  15. Nice try Samy[ Go to top ]

    Mahendran -

    Nice try sir :)

    Or, should I call you Samy? ;)

    Dion

    http://ajaxian.com
  16. Test[ Go to top ]

    test
  17. RE: Apache Pluto 1.0.1 released[ Go to top ]

    If you're doing portlet development, is Pluto your development environment? If not, why not?

    Oh I don't know maybe because the user docs are incomplete, arcane and error prone. And the error messages (stack traces) are ridiculous and have nothing to do with the actual problem. Ever heard of a precondition and a postcondition? These are nice for narrowing down the actual problem instead of throwing generic stack traces, which are three mile long and utterly useless. Nothing like getting a NullPointerException when you are missing a jar file in your WEB-INF/lib dir.

    BTW Thanks for not documenting what jar files must ship with a Pluto Portlet or do you even know.

    You need a concise, step by step, getting started with Pluto guide.

    I am new to Portlet development. We are targeting WebSphere Portal Server. It takes about an hour to start up (more like three minutes but it feels like an hour).

    The one thing I love about Pluto is it starts in 2 seconds (1.7 to be exact) unless of course you are using a Mac then double it. (Yes I have a Mac too. I can't wait to get my MacIntel!)


    I did a complete write up on my experiencing getting Pluto up and running. I wrote a simple HelloWorld portlet and then futzed around with Pluto and said Portlet until it ran.

    You can find it tomorrow at http://www.jroller.com/page/RickHigh

    All you will see now if me griping and moaning about WebSphere Portal and JetSpeed2 (http://jroller.com/page/RickHigh?entry=lighter_faster_yada_yada_yada).

    I have *not* posted my experience on Pluto yet.

    BTW I plan on using Pluto for development.

    Next on my hit list is JSF Portlet Bridge. I hope it compiles unlike JetSpeed 2, which did not. I want a really lightweight env. to do Portlet/JSF development.

    Hey Rickard feel free to pimp your Portal! I'd like to here more about it.
  18. RE: Apache Pluto 1.0.1 released[ Go to top ]

    If you're doing portlet development, is Pluto your development environment? If not, why not?
    Oh I don't know maybe because the user docs are incomplete, arcane and error prone. And the error messages (stack traces) are ridiculous and have nothing to do with the actual problem. Ever heard of a precondition and a postcondition? These are nice for narrowing down the actual problem instead of throwing generic stack traces, which are three mile long and utterly useless. Nothing like getting a NullPointerException when you are missing a jar file in your WEB-INF/lib dir.BTW Thanks for not documenting what jar files must ship with a Pluto Portlet or do you even know.You need a concise, step by step, getting started with Pluto guide.I am new to Portlet development. We are targeting WebSphere Portal Server. It takes about an hour to start up (more like three minutes but it feels like an hour).The one thing I love about Pluto is it starts in 2 seconds (1.7 to be exact) unless of course you are using a Mac then double it. (Yes I have a Mac too. I can't wait to get my MacIntel!)I did a complete write up on my experiencing getting Pluto up and running. I wrote a simple HelloWorld portlet and then futzed around with Pluto and said Portlet until it ran.You can find it tomorrow at http://www.jroller.com/page/RickHighAll you will see now if me griping and moaning about WebSphere Portal and JetSpeed2 (http://jroller.com/page/RickHigh?entry=lighter_faster_yada_yada_yada). I have *not* posted my experience on Pluto yet.BTW I plan on using Pluto for development.Next on my hit list is JSF Portlet Bridge. I hope it compiles unlike JetSpeed 2, which did not. I want a really lightweight env. to do Portlet/JSF development.Hey Rickard feel free to pimp your Portal! I'd like to here more about it.

    My thoughs on this subject:

    http://jroller.com/page/RickHigh?entry=if_you_re_doing_portlet

    http://jroller.com/page/RickHigh?entry=pluto_faster_lighter_portal_development
  19. RE: Apache Pluto 1.0.1 released[ Go to top ]

    Rick,

    Thanks for posting this information here and on your blog. I'll take your feedback to heart and see if I can't incorporate some of it into documentation changes. One thing the Pluto team has struggled with is building and getting input from the community. I encourage you to chime in on the user and developer lists. I'll be happy to work with you to resolve your issues.

    Just recently we've added a couple more committers and hope to continue to build momentum. I think we all recognize the need to improve USABILITY and Documentation. The usability side of that is really the focus of the 1.1 rewrite. It aims to simplify things for embedders, developers, and users. As far as documentation, we're working on it, but it's definately the not our strong point -- patches are welcome!

    David
  20. Does Puuto supports WSRP[ Go to top ]

    Hi: I am a newbie and evaluating Pluto to be included in our portal. I did not see any reference in to the DOc to WSRP. My question is does pluto supports WSRP?

    Thank you.