JAX 2009: JSR-301 (summary & (unfair?) rant)

Flame On!(Disclaimer: this text was written while listening to the presentation – please be forgiving with errors that might result from both listening and writing)

Andy Bosch was our second target on day two of the 2009 JAX. He is going to talk about the JSR-301 specifying bridges between JSF and portlets. Since portlet integration with JSF is one of the next topics in an internal project at QuinScape I was naturally very curious about how much currently is possible (having experienced myself that portlets usually are the ugly step child of web projects). We learned…

Andy will give reasons for combining portlets and JSF, explain JSR-301 and the meaning of JSR-329 and its meaning for connecting portlets and JSF. A short survey showed that about 99% of the audience is using JSF but only about 60% are using portlets.

The main reason for wanting to combine both technologies is somewhat contrived: “I want to use a higher abstraction level for displaying my web pages. Nobody is writing servlets any more to generate HTML.”

Mmmmhhh…  I could use Wicket or Tapestry or… whatever. Where are the JSR-bridge-attempts for that? Ok, JSF is a standard. Oh well. Personally I feel that JSF is a very bad standard (basically sub standard in quality) but okay, I can grog that. So we want to connect portlets and JSF because both are standards – if mediocre ones as far as I am concerned.

Now, where is the problem in doing so? Both technologies define a lifecycle and these lifecycles must be combined in order to define who calls whom and in what way. This is the reason behind JSR-301. JSR-301 provides the appropriate glue code for JSF 1.2 and portlets 1.0. JSR-301 was started in 2006, JSR-329 is the standard to combine JSF 1.2 with portlets 2.0. The goal is to basically add some JARs and add a configuration in order to be able to combine portlet and JSF technologies with as little as pain as possible.

The basic idea of JSR-301 is to provide a generic faces portlet that then delegates calls to the standard faces servlet providing the JSF integration. So the portlet container has a special portlet that then controls the underlying faces servlet. The biggest challenge is the lifecycle mapping between both standards.

The approach is the map the first five phases of the JSF lifecycle to the portlet action request and use the restore view and render phases of the JSF lifecycle for the render request of the portlet render phase. A problem with this solution is that JSF messages generated during validation (if a validation error occurs) can’t by default be propagated to the render phase because portlets do not allow that. The solution seems to be the introduction of an extra scope – the bridge request scope – which is used for storing such messages.

The reference implementation happens in the Apache MyFaces project but can be used for any JSF applications.

So, what do I actually need to do to configure my system for using this fabulous bridge. The steps are:

  1. Develop a normal JSF application.
  2. Remove forbidden tags like <html>, <head>, etc.
  3. Add the JSR-301 JARs.
  4. Add the portlet.xml and the GenericFacesPortlet.
  5. Deploy and have fun… urgh.

Andy stressed that this cooking receipt works for “standard JSF applications”. Considering the many non-standard approaches that current JSF libraries use to implement AJAX, resource serving, etc. I started to wonder for how many real world applications this truly works. I continue to be bewildered by how much effort goes into a rather trivial technology that continues to evolve at snail speed.

Andy then proceeded to explain the five steps above in more detail. I’ll refrain from describing these details – the efforts include configuring views for the various portlet modes. At least the view mode must be configured, the rest is optional. One special feature is “ExcludedRequestAttributes“. To repeat: the bridge stores all attributes defined by JSF in the action phase in order to provide them once more in the render phase. If for some reason one does not want to store such attributes for the next phase, I can configure this declaratively with this attribute. Why would I want to do that? I have no idea. Yet another example for a useless feature of a rather useless technology. Andy failed to give a real world example (note: we are talking about attributes, not parameters). Ugh. My guess would be one of the portlet technology providers in the committee is having some kind of problem with his particular platform and needed this “feature” to solve this.

The next option is “PreserveActionParams” which allows to preserve parameters for the next phase. Here I can see that we might need this in order to integrate standard web applications that might be surprised by the specialized portlet behaviour of forgetting parameters between the render and action phase. Rich Faces for example requires this.

Finally Andy addressed component libraries. There seem to be between 20 and 40 of these libraries. Do they work with the bridge? Maybe? You will have to check each library on your own… see my concerns above. The main culprit for problems are the servlets that usually are shipped with these libraries and cause problems with the bridge.

Andy provided a very good presentation and adressed all relevant issues. It’s not his fault that I still believe to be portlets in particular but also JSF in general to be rather problematic, primitive and by todays other standards retarded standards that cost more than they provide benefits. There’s no such thing as a free lunch…

P.S.: I failed to blog about Andys excellent session yesterday afternoon which presented JSR-286 and was a very good overview. If not particularly interesting since JSR-286 is a rather trivial evolution of JSR-168 for which I just can’t understand what good reason justifies the long time that has passed since JSR-168. Probably that real life does not really portlets the way they currently are implemented and only very few companies are using them due to cost reasons and lack of support for almost all modern web technologies. Amazing that companies still manage to sell portlet servers for anything resembling a monetary exchange. Sorry for ranting again… Java portlet standards for the time being remain a solution looking for a problem to solve as far as I am concerned. Not because the idea of portlets is bad but because the actual technological standard is lacking in so many respects that I’m yet again ranting. Oh well.

Comments are closed.