Skip navigation

GateIn

5 Posts authored by: Julien Viet
Julien Viet

GateIn 4.0

Posted by Julien Viet Jan 23, 2013

GateIn 4.0

 

GateIn 3.0 was released almost 3 years ago as the result of the collaboration of the eXo Platform and Red Hat team. The team worked then on a serie of improvements for 3 years until the recent GateIn 3.5: the project improved and gained maturity among releases, specially with the recent 3.5 release. The main goal of GateIn 4.0 is to rework the portal engine: the current engine has aged enough for being replaced by a more modern engine for providing better everything.

 

This project is important to me: I left Red Hat for eXo Platform in 2008 and I was working on the future JBoss Portal 3.0 at this moment and I left some unfinished ideas. During the GateIn collaboration other ideas came, some were implemented in GateIn, some could not due to the architecture. 4.0 is for me the opportunity to work this out.

Juzu

 

The Juzu Web framework will be used for rebuilding the aggregation engine: a portal before all is a web application and the idea is to let Juzu focus on the web part and leave to the GateIn engine focus on being a set of controllers (in the MVC way) for aggregating content or editing it.

 

Juzu was started a year ago, it provides since version 0.6 a servlet mode that makes it able to deliver web applications in addition of portlet applications. Of course it embeds some part of GateIn already in it, for instance the Juzu route controller is an improvement of the route controller of GateIn.

 

Juzu relies on the JSR-330 specification for wiring components and provides therefore a standard programming model. It integrates with Annotation Processing for doing wonderful things with Java (yes we not planning to rewrite GateIn in another language).

 

The project

 

The main focus is to rewrite is the portal engine with the serving of portal pages based on a better model and the native portal applications: the page edition for example. The scope is well defined and is defined in the In Place Editing specification . It describes an evolution of the current GateIn model written by Benjamin Paillereau, his great work is the essence of the feedback provided by many customers, integrators and other users.

 

A key part of the technical aspect is the aggregation engine: it will be based on the big pipe technology for providing increased performances and better latency for page rendering. The portal will also push to the client the stale portlets: for example you define a cache timeout of 1 minute for a portlet will result in GateIn updating the portlet fragment every minute.

 

Beside this we are have other goals (not extensive)

 

  • Better usability and configuration for providing a better experience
  • 4.0 will give you the possiblity to embed GateIn with an in memory implementation that provides a fast and stateless portal for testing purposes
  • Rebase the skinning and layout on Twitter Bootstrap

The road

 

GateIn 4.0 will not be the next GateIn release right away, we have plans to provide additional GateIn 3.x releases that the team is currently working on. Nevertheless GateIn 4.0 development has started recently, you can follow the development on the gatein-dev mailing list "GateIn 4.0.0" thread. I bootstrapped this work a few weeks ago and I welcome anyone wanting to contribute to join us on the list.

 

Open source and open minded.

GateIn 3.4 M1 is the first milestone for the upcoming 3.4 release, it provides two new features: JavaScript modules and mobile redirect. You can download the release from this page, try it and give us feedback in the forums.

 

Matt blogged a few days ago on the mobile redirection, so I will just highlight the improvements that were made on the JavaScript side and explain why it is a key feature of GateIn 3.4.

 

GateIn is an aggregation platform, until now you used GateIn as an efficient way for aggregating markup in a web page. With the rise of JavaScript, GateIn is now a platform for aggregating JavaScript. The only correct way for aggregating scripts in a page is to use the JavaScript Module pattern, supporting JavaScript modules in GateIn is a key point and that's what we achieve with GateIn 3.4.

 

GateIn 3.3 improved by far the management of Javascript in GateIn focusing on two aspects :

 

  • Cacheable URL for Javascript: for instance by including script characteristic in the URL like the GateIn release number, the minified flag and so on.
  • Lazy loading of script: loading triggered by a portlet or a portal, dependency management between scripts, parallel loading, etc...

 

Our initial goal was to improve web performances and we achieved it. The 3.4 release add two missing pieces to the puzzle: isolation and asynchronicity. The Requires.JS implements the Asynchronous Module Definition and is a tiny piece of Javascript that focuses on delivering those two pieces and we integrated it in GateIn 3.4. In fact we replace GateIn custom Javascript loader by Requires.JS loader.

 

The key difference with GateIn 3.3 is how JavaScript is managed and how dependencies are connected between each other. In GateIn 3.3 you can provide script that would consume and produce global modules:

 

 

producedModule = {
  service : function() {
     consumedModule.service();
  }
};

 

With asynchronous module, the script is written a bit differently:

 

_module = {
   service : function() {
      consumedModule.service();
   }
};

 

This script is declared in the gatein-resources.xml descriptor as a module:

 

<module>
   <name>producedModule</name>
   <script>
      <name>MyScript</name>
      <path>producedModule.js</path>
   </script>
   <depends>
      <module>consumedModule</module>
</module>

 

The change here is that now we use the implicit variable _module, in reality when you do this script, the whole script is wrapped by GateIn thanks to the XML declaration:

 

define("producedModule", ["consumedModule"], function(consumedModule) {
   var _module = {};
   // your code wrapped here
   return _module;
});

 

The define function is a Requires.JS construct and from here the code evaluation (i.e the module definition) will be entirely managed by Requires.JS. Requires.JS will do its best to load the module asynchronously and in parallel to deliver the best performances. This JavaScript construct provides the two essential things we are looking for:

 

  1. The execution of the script is deffered until it's really needed thanks to the function wrapping the code
  2. Isolation works because we the function arguments are used instead of the globally scoped variables and the returned _module

 

We expect to release GateIn 3.4 around september with those two features finished. GateIn 3.4 will provide two key features : mobile redirection support and JavaScript modularity.

Julien Viet

GateIn 3.3

Posted by Julien Viet Jun 4, 2012

GateIn 3.3 is released today, 3 months after the 3.2 version, you can download it on this page.

 

A few months ago we decided to change our way to drive the GateIn project and provide more frequent releases to our community. Meanwhile we migrated our source repository to Git on GitHub that gives us the opportunity to have a different approach for our workflow on the GateIn project.

 

Until now, we used to integrate all current features in the GateIn SVN trunk, as a consequence, the trunk source code was containing different features being integrated or developed in the trunk. Some were finished, some were still a work in progress and some in an inception status. With this very centralized approach, it was never really the time to make a release because the unfinished features were not ready for releasing.

 

After GateIn 3.2 we moved to Git and decided instead to work with feature branches and have in the master branch only a few features scheduled for the next release. Thanks to this approach, it is easier for us to deliver more frequent GateIn community releases because we integrate only what will be released in a nearly finishes state.

 

Anyway, I think it's time to dive into the new features!

 

AS7 update

 

We are proud to announce that JBoss Application 7 is now a first class citizen among servers we support in GateIn. You can enjoy the benefits of GateIn on the fastest JBoss AS ever created. Take a look at the instructions here and play with the packaging!

SAML2 integration

 

Security Assertion Markup Language (SAML) is an important and widely adopted standard related to authentication and authorization mechanism. You can now benefit of this standard thanks to our flexible integration into GateIn Portal. Marek provided more insight into technical details in a recent blog post.

JQuery

 

JQuery is today almost a standard by itself, we are glad that now GateIn is based on JQuery for providing its rich UI. As a consequence JQuery is provided out of the box with GateIn and you can use it directly in your portlet.

 

GateIn uses JQuery 1.7.1, however if you are willing to use another JQuery version you can bundle your own version:

 

<gatein-resources
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.gatein.org/xml/ns/gatein_resources_1_2_1 http://www.gatein.org/xml/ns/gatein_resources_1_2_1"
        xmlns="http://www.gatein.org/xml/ns/gatein_resources_1_2_1">
  <module>
    <name>jquery-1.6.4</name>
    <script>
      <name>jquery-1.6.4</name>
      <path>/javascript/jquery-1.6.4.js</path>
    </script>
  </module>
  <portlet>
    <name>JQueryPortlet</name>
    <module>
      <script>
        <name>myscript</name>
        <path>/javascript/myscript.js</path>
      </script>
      <depends>
        <module>jquery-1.6.4</module>
      </depends>
    </module>
  </portlet>
</gatein-resources>

 

This gatein-resources.xml file must be located in the WEB-INF directory of your web application. It instruct GateIn to use JQuery 1.6.4 when the JQueryPortlet appears on a page, along with a custom myscript.js for the portlet that would depends on JQuery. A full example is available among the examples named gatein-jquery.war .

Javascript modules

Javascript serving is an important concern for modern web applications and specially for portals. A portal is an aggregation engine and provides different applications in the same page having for consequence to potentially have to deliver many javascript files on the same page which can severly affect performances. We have worked to provide a better modularization of Javascript and more specially define a real dependency system for Javascript resources. This dependency system allows us to know exactly which scripts should be served when a page is displayed based on a declarative configuration.

Module definitions

Javascripts resources are now bundled in modules, each module is managed by GateIn asset server and are declared in the gatein-resources.xml file. This resource descriptor already had a mechanism for achieving this result, but the dependency system was not good enough so we had to make it evolve to support more precise semantics.

 

A module bundles a set of Javascript files, those files are aggregated into a single resource when they are served by GateIn for more efficiency, for instance:

 

 <module>
    <name>jquery</name>
    <script>
       <name>jquery</name>
       <path>/javascript/jquery-1.7.1.js</path>
    </script>
    <script>
       <name>jquery-alias</name>
       <path>/javascript/jquery-alias.js</path>
    </script>
 </module>

 

This module bundles two scripts and is named jquery.

Module dependencies

Of course modules can define dependencies upon each other, this module declaration defines the common module having a dependency on the base module.

 

 <module>
    <name>common</name>
    <script>
      <name>eXo.core.DragDrop</name>
      <path>/javascript/eXo/core/DragDrop.js</path>
   </script>
   <depends>
      <module>base</module>
   </depends>
 </module>

 

It means that when the common module is served, the base module will be served and executed before the common module scripts.

Module scopes

Scopes are very important for modules, they define when they are served by GateIn, there are three modules scopes

 

  • Shared scope : the shared scope is just like a library and it is not served by default (except the special bootstrap module that provide base services for loading other scripts)
  • Portal scope : the module is attached to a specific portal entity when it is served
  • Portlet scope : the module is attached to a specific portlet and is served when the portlet appears on the screen

Module internationalization

Last but not least, modules are internationalizable. It means that GateIn can filter the scripts and replace ${} keys with values from a resource bundle. This allows us to avoid resource bundle loading from the client and provides better performances.

 

 <module>
   <name>base</name>
   <supported-locale>de</supported-locale>
   <supported-locale>en</supported-locale>
   <supported-locale>fr</supported-locale>
   <supported-locale>ru</supported-locale>
   <supported-locale>vi</supported-locale>
   ...
</module>

 

Javascript serving

The javascript server has been rewritten to use the module system. It has also been integrated with the famous navigation controller that was introduced in GateIn 3.2 . This enables GateIn to provide better urls for javascript, let's see how a module url look like:

 

/portal/scripts/3.3.0-CR01-SNAPSHOT/SHARED/base-fr-min.js

 

We can see in the url several parts:

 

  • The current server version 3.3.0-CR01-SNAPSHOT
  • The module scope SHARED and name base
  • The current user language fr (because I'm french). This language is optional and only appears if the module contains at least a supported locale definition.
  • Finally the name min suffix is the minified version of the module

 

Those parts provide true cacheability of the module which is a key point in web performance today. Note that the server is fully dynamic and you can change a part in the url to see a different result. For instance if we remove the min suffix you will obtain the non minified version which is useful for debugging.

 

This serving is made easy thanks to the navigation controller system in GateIn. The navigation controller provides you a fine grained configuration of the server urls, it means also that if you don't like how GateIn module url are designed you can change it easily!

 

In the controller.xml file you can find a section for the resources:

 

<route path="/scripts/{gtn:version}/{gtn:scope}/">
   <route-param qname="gtn:handler">
     <value>script</value>
   </route-param>
   <path-param qname="gtn:version" encoding="preserve-path">
      <pattern>[^/]*</pattern>
   </path-param>
   ...
</route>


 

We can easily see how it works! Of course this is fully dynamic, if you change this file and reboot (or force a reload via JMX) urls will updated instantaneously.

 

What's next ?

 

We're already working GateIn 3.4 and 3.5. I see great features coming in the pipe:

 

  • GateIn mobile suppport preview : we do have a complete roadmap for providing full mobile support in GateIn 4.0, this will be our first milestone of this work.
  • Asynchronous Module Definition : an evolution of the module system already in GateIn 3.3 with a reword of the Javascript Loader.
  • The first milestone of the GateIn public API that will provide stable APIs for integrating with GateIn

 

If you want to contribute or follow GateIn development you can use the new community development space for GateIn, in particular the specification directory.

Julien Viet

GateIn 3.2 M1 reached

Posted by Julien Viet Jun 26, 2011

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

 

Screen shot 2011-06-26 at 11.05.28 PM.png

Screen shot 2011-06-26 at 11.08.46 PM.png

 

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.

Navigation is an important concept of GateIn, it allows to organize web pages as a hierarchical navigation tree for portals and groups. We have been working hard to improve this part of GateIn and one of the most awaited feature asked by our community is about providing a fully internationalization support of navigation node.

 

Internationalization in navigation was supported until now with the help of resource bundles by providing a label containing a specific expression (like ${portal.home} for instance). While this works fine it is sometime not dynamic enough as it requires to update a resource bundle when a new navigation node is added to handle custom resource bundle keys.

 

The next version of GateIn will support fully dynamic support of navigation i18n. The setup can be done easily in navigation.xml file in a similar fashion of portlet.xml (using the xml:lang attribute to specify a language) deployment descriptor.

 

 

This feature will soon be extended with a UI to allow modification at runtime in the web administration, I'll follow up with screenshots.