JBoss: software development »GateIn 3.2 M1 reached

GateIn 3.2 M1 reached: "

We have just released the first milestone of GateIn 3.2 last week and I wanted to make a follow up post to Bolek's post to explain a bit the various features you will find in that release.

First I would like to shed some light on the feature coming in this release and the forthcoming milestones. GateIn 3.2 is a logical evolution of GateIn 3.1 release and the vision is to improve the existing project in various ways, some of them are already in that release and of course the next milestones will bring new features, you can expect a follow up post soon that will provide more insight about GateIn 3.2 roadmap.

If you are a bit familiar with GateIn, you have perhaps heard about the GateIn WCI component that aims to abstract the servlet container runtime to make GateIn Portal isolated from the current servlet container runtime. By adding new runtime support in WCI, we are able to make GateIn ported to those platforms and this is what we have done in the M1 release with the support for Servlet 3.0 based containers (Tomcat 7 and JBoss AS 6) and the Jetty server so now we deploy to the following platforms:

1. Tomcat 6 and 7
2. JBoss AS 5.1 and 6
3. Jetty 6.1

Actually the support for Jetty 6.1 was already done for a long time but we never took the time to properly finish it and we finally did it. It was actually something that improved the quality of the portlet container as it helped us to find a few bugs that would not happen in Tomcat / JBoss but only in Jetty (Tomcat / JBoss are very similar containers).

When eXo donated the GateIn code to JBoss.org it was relying on a custom build tool build on top of Maven and we put a lot of energy to decouple GateIn build from it and now we're proud to say that we have a 100% compliant Maven build that works with Maven 2.2.x and Maven 3.x (so you can enjoy parallel build if you like). That was in our opinion an unnecessary barrier for people wanting to contribute to GateIn and it was important for GateIn community to eradicate it.

Sometimes there are features that are hard to name, we had one in GateIn and we called it site describability, it's quite minor yet enhance the usability of GateIn by allowing the provide a display name and description for a portal site, I made a couple of screen shots to show you that feature

As a portlet developer you often need to extend the GateIn server and create portlets that interact with the environment, you will likely enjoy this new feature of GateIn 3.2 that allows you to obtain contextual information like the current navigation URI, the current page name and so on. The best think in that feature is to leverage the JSR 286 API to get this information in a very intuitive and natural fashion. If you think about it, the most adapted way to obtain this information is via the public render parameter API. This feature is therefore very easy to use as the only thing you need to do is to declare a specific public render parameter in your portlet XML deployment descriptor, for instance if you want to obtain the current site name you will need to declare:

<portlet>
   ...
   <supported-public-render-parameter>site_name</supported-public-render-parameter>
   ...
</portlet>

<public-render-parameter>
     <identifier>site_name</identifier>
     <qname xmlns:prp='http://www.gatein.org/xml/ns/prp_1_0'>prp:site_name</qname>
  </public-render-parameter>

And voilà, at runtime you can get the current site name by using the portlet request render parameters, pretty much like

protected void doView(RenderRequest req, RenderResponse resp) throws PortletException, IOException {
   ...
   writer.println('The current site is ' + req.getParameter('site_name'));
   ...
}

Everything we could find useful to be provided was done (and if you think that we forgot something useful, don't hesitate to tell us, or even better contribute it!):

• navigation_uri : the current navigation URI
• page_name : the current page name
• site_type : the current site type ('portal' for portal, 'user' for dashboard, 'group' for group)
• site_name : the current site name
• window_width : the current window width
• window_height : the current window height

We have made a lot of minor enhancements that will make your life better with GateIn, I will explain the most relevant ones:

• Resource compressor : we provide plugability now for resource compression (Javascript and CSS) and we integrate the YUI and Google Clojure compressors by default. It works with a system of plugins, if you want to change the configuration you can have a look at the resource-compressor-configuration.xml file. You can even develop your own compressor if you need.
• Use a drop down list for portal or group sites when adding a new page, it's a minor usability enhancement, yet convenient.
• Lot of work was done to make the deployment of the WSRP service more modular in JBoss AS, just how it use to be in JBoss Portal.
• The portlet container session life cycle was sometime having a life time greater than the portal one, specially when a logout was performed, we just fixed it, so a logout on GateIn invalidates pending portlet sessions.

I just scratched the surface over all the minor issues that are available in this release, you can expect in the next milestone new features, specially concerning the navigation, lot of work is being done in that direction, this code will be merged in the coming days and we intent to make an M2 for that purpose (actually the M1 was so late because of those two features): it improves the way that GateIn handles navigations and it will fix a performance issues when extra large navigations are used (by extra large I mean 2000 pages, not 20 or 200), the other improvements will provide full internationalization for navigation label but I already talked about it in this blog.

"