eXo Platform v2, Portal, JCR, ECM, Groupware and Business Intelligence

The goal of this paper in two parts is to describe our product line strategy, the refactors and new features we introduced in version 2 as well as our vision on what type of software we want to build.

It has been a while since we published our last article on TSS in August 2004.

Since that date we have seen many of our expectations become a reality and many of our technical choices being validated:

  • The wide adoption of lightweight containers,
  • The wide adoption of Java Server Faces,
  • The creation of third party – JSR 168 compliant – portlets such as collaboration SyncEx ones,
  • The release of the Java Content Repository (JCR – JSR 170) specification.

As well as many changes on the OSS ecosystem and industry:

  • An ever growing competition on Open Source Software (OSS) portals that are now seen as viable alternatives to closed source solutions such as IBM or BEA ones,
  • More and more companies providing end user targeted OSS products on broad scope such as Enterprise Content Management (ECM), Customer Relationship Management (CRM) and Business Intelligence (BI).
  • An ever-growing trend for OSS with more and more Venture Capitalists (VCs) entering the game thus changing the rules of it.

As well as many unexpected one such as the Java Script comeback with AJAX!

The goal of this new paper in two parts is to describe our product line strategy, the refactors and new features we introduced in version 2 as well as our vision on what type of software we want to build.

Therefore we will first present an overview of what eXo Platform v2 is. We will explain why version 1 was more a portal framework while version 2 is now a core part on which we build an extensive product line that will also target end users. This product line will contain elements such as a Portlet Container, a Portal, a Java Content Repository (JCR – JSR 170), an Enterprise Content Management (ECM) solution, a Business Intelligence (BI) platform and many more to come.

In that first part, geeks will find what they are looking for in the second section as the first one describe the new product line from a high level point of view.

These articles comes with the release of:

  • eXo Platform v2 RC1,
  • eXo Portal 1.1 RC1,

for part 1 and with:

  • eXo JCR 1.0 RC2,
  • eXo ECM 1.0 RC1

for part 2

That you can download from ObjectWeb site ( http://forge.objectweb.org/projects/exoplatform/ ).

Part 1: Product Line Overview

eXo Platform v1 is a Portal framework that was built to provide a scalable, modular, extensible and easy to configure solution on which Integrators, Independent Software Vendors (ISVs) and Value Added Resellers (VARs) could build their offering. But, it was not intended to be used out of the box unless the company or organization had a dedicated technical team.

While exploiting v1 with community, partners and customers we realized that the product line approach fits best for the end user customers who need to get ready to use packaged solutions. Furthermore, providing a monolithic product for portal, enterprise content management, groupware and business intelligence tend to scare people even though, thanks to Maven, the packaging and selection of portlets as well as services to deploy was easy.

Therefore, as the product became more mature we decided to adopt the product line strategy. In other words we are building a core platform on which we implement products that can be inter dependant such as the ECM that depends on the Portal.

Of course this also comes with some maintenance overheads (unit and web unit tests, deployment scripts, custom installers, custom web design, custom documentation and related enterprise support) that we are now able to overcome as the number of committers and employees dramatically increased.

The previous schema shows the product set. All products are built on top of the platform and some may depend on other. For instance, the ECM product depends on the JCR and Portal ones. The Groupware product depends on the ECM one and therefore on the Portal and JCR ones. We will come back on those dependencies when presenting each product in detail in the next paragraphs.

We also provide release estimation for the product. Those of course takes into account the documentation writing and therefore you may already be able to deploy RCs or build stable versions from the Subversion repository still located on ObjectWeb forge.

Here is a brief overview of each product:

  • The Platform contains the container kernel as well as the logic to analyze services configuration XML. It also comes with a set of reusable services such as security, organizational or chart ones. No distribution is built out of it and maven artifacts are only installed to a local repository to be leveraged by other products. The license of this part is now LGPL and should be released in early Q1 2006. The best way to use it will be to import the library from Maven 2 ObjectWeb or Ibiblio repository.


  • The Portlet Container 1.1 contains few modification compared to version 1.0 contained in eXo Platform v1 and therefore we will not describe the changes in a dedicated paragraph. The source has been adapted to rely on the service configuration XML defined for v2 and AspectJ dependency has been replaced by a chain of interceptors in pure Java. The object pooling has been disabled by default as modern JVM now manage object creation and garbage collection in a more efficient way. ISVs that whish to provide - JSR 168 optimized technology- to their portal or application without building one themselves, uses this product. We should release the product in early Q1 2006 at the same time we release the final version of the platform.


  • The Portal 1.1 is built on top of the platform and relies on the portlet-container to manage its administration portlets and third party ones. As for v1 the portal and the core portlets are using Java Server Faces to provide extensive dynamic functionalities that we will describe in detail in the dedicated paragraph. Nevertheless, we improved the JSF renders. They now do not contain Java code anymore but delegate the rendering to velocity templates, which increases flexibility. Apart those changes many new features have been added (and funded by customers) mainly to enhance security granularity, ergonomics and web design. We should release the product in early Q1 2006 at the same time we release the final version of the platform.


  • The eXo JCR 1.0 is an implementation of the JSR 170 specification that includes all the required functionalities (level 1, 2 and all optional features) such as document definition, searching capabilities, import/export functionalities, locking, versioning and many more that we will describe in details a bit later (part 2). The default implementation is based on a relational database implementation and has been tested on major products such as Oracle, DB2, SQLServer, MySQL… Other custom implementation should be done in 2006. The repository can also be reached through WebDAV. The product will be released in early Q1 2006 at the same time we release the final version of the platform


  • The ECM 1.0 goal is to provide a set of tools on top of the Portal and JCR content store to enable advanced document management functionalities as well as several publication channels including web publishing. Among those features we can find WebDAV interaction, Publication Validation Workflow with delegation support, document backup, template mechanism to create and visualize structured documents. The introduction of the “Action” concept allows Business Process, Drools Rules or Groovy Scripts to be launched or executed when documents are read, added or removed from a dedicated JCR workspace. The product will be released in Q2 2006 but most of the functionalities are already available in the first RC. Though, we need some more time to tune, test, document and package that solution, any one that feel courageous enough can start using it or build on top of it.


  • The eXo BI 1.0 is an enhanced integration of the ObjectWeb project SpagoBI (http://forge.objectweb.org/projects/spagobi) that relies on the Portal and the eXo JCR implementation to store BI reports. That product tends to unify, using a single web interface, all the different types of BI reports that include OLAP, SQL reports as well as Data Mining ones and to provide thanks to the use of portlets a personalized view of them. Furthermore, it goes behind the mono product offering and allows you to create commercial product based reports such as the one of BusinessObjects and to present them through the same portal channels as if the reports were done using open source products. For more details, refer to the dedicated paragraph in part 2 of this article. The first version will be available from SpagoBI site as we did for xWiki portlet. A fully integrated solution relying on the ECM product will then be released and will be distributed from our web site.


  • The eXo Groupware 1.0 is a set of portlets and services such as forum, web mail, shared calendar or wiki that provide users with collaboration functionalities. That product relies on the Portal, JCR and ECM ones. Indeed, we package a set of portlets that display structured content defined and stored in the JCR (for example forum threads or messages) and that can therefore leverage all the standard functionalities such as versioning, locking… That product also includes some integration with third party ones such as a deeper integration with xWiki, www.xwiki.org (a Wiki engine part of ObjectWeb) and SyncEx collaboration portlets from Yash Corporation – www.syncex.com (portlets that provide Microsoft Exchange information). That product will be fully available during the second part of 2006 but several components such as the forum or the web mail will be ready before that and you will be able to deploy them in the Portal 1.1.


As end users are now directly targeted with our product line strategy, we have introduced an Annual Support Subscription model a la RedHat. OEM and ISV can still purchase the commercial license if the GPL one does not fit their needs. The prices will be placed on our web site as soon as we have upgraded it to the new eXo version.




Annual Support Subscription

Release Date

eXo Platform v2



2006 Q1

eXo Portlet Container v1.1

GPL or



2006 Q1

eXo Portal v1.1

GPL or



2006 Q1

eXo JCR v1.0

GPL or



2006 Q1

eXo ECM v1.0

GPL or



2006 Q2

eXo Business Intelligence v1.0

GPL or



2006 Q1: from SpagoBI site (LGPL)

2006 Q2: full integration

eXo groupware v1.0

GPL or


Including licenses of third party add ons


Q3 2006



From an architecture point of view the technical stack that goes up to the ECM product can be modelized as in the next screen:

In eXo Platform v1 and v2 all the business logic is encapsulated in services that are dependant but loosely coupled thanks to Inversion Of Control (IoC).

Therefore, each product as shown in the first image is composed of a set of services, portlets that query them and one or several portal instances that are simple web application (war) with dedicated configuration and web design (note that each portal instance can define its own preconfigured organization model or security policy as well as many other configurations such as the predefined portal template pages to use when new users are created which can be useful for hosting environments). The service container layer is responsible of gluing the services.

The portlet container is a service as well as the portal layer except the rendering part of it that is based on JSF.

Upper the stack, the JCR implementation is also a service that reuses eXo services located in lower stacks such as the caching service, the organization service or the security one. Finally on top of all those services and portal instances we have the portlets whose lifecycle is managed by the portlet container while the portal is responsible of the page aggregation.

Therefore, if you look at the Enterprise Content Management product you will see that it is composed of a set of services such as the Workflow service, the JCR service, the Template service, the Rule service, the Script service and the ECM service (the last ones are all packaged in the ECM service jar). Those are then used by the portlets – workflow and ECM ones - that are added to a dedicated ECM portal instance distribution. That portal war comes with a set of predefined group and users with different roles in order to manage the document flow.

As you can see adding a product module is a simple packaging process that we will discuss more in the next paragraph. It is a process that we advise to any portal builder as it allows to clearly differentiate eXo products code with his code and to use the build and deployment framework now based on Maven 2.

1. The Platform


  • New Product module organization


The Core Platform overall architecture and packaging is quite similar to what we did in version 1. It is still built on PicoContainer to inject the service dependency but it comes with more reusable services and of course Portal or ECM business logic services have been extracted and moved to dedicated product modules.

Hence, when deploying a product you first have to build and install all the services, portlets and portal instances of all the product modules it depends on. Then the components of the product itself can be built and then deployed using the eXo Maven plug-in that will deploy the artifacts either in Tomcat or as an Enterprise Archive (EAR).

The next screenshot shows the directory that contains the source code of eXo Platform v1.0.1. It is a modified version of 1.0 that mainly contains bug fixes.

The source packaging is similar to the one we have in v1. The v1.0.1/build directory contains the main Maven 1.0 files that will launch a multi-project build. Indeed, each other sub directory is or contain a maven sub project that will produce its own artifact (archive of type jar or war).

Hence, each project creates and installs the Maven artifact in the local repository to be then used by the other subproject while building, testing or deploying. Then, the distribution is built by calling the eXo maven plug-in custom goals.

The next screen-shot shows the new directory structure for version 2. As you can see there exists several exo-*/ product modules under the v2.x/ directory. Each of them may contain a set of services, portlets and portal instance like v1 exo-platform or sample projects we introduce in the documentation.

The exo-platform module also contains the source for the container and some common classes that can be reused (mainly as static method calls).

  • The Service Container

The container package is responsible of building a hierarchy of containers.

Each service will then be registered in one container or the other according to the XML configuration file it is defined in. It is important to understand that there can be several PortalContainer instances that all are children of the RootContainer.

The behavior of the hierarchy is similar to a class loader one, hence when you will lookup a service that depends on another one the container will look for it on the current container and if it does not find it then it will look in the parent container. That way you can load all the reusable business logic components in the same container (here the RootContainer) and differentiate the service implementation from one portal instance to the other by just loading different service implementation in two siblings PortalContainers.

Therefore, if you look at the Portal Container as a service repository for all the business logic in a portal instance then you understand why having several PortalContainers allows you to manage several portals (each one deployed as a single war) in the same server by just changing XML configuration files.

The default configuration XML files are packaged in the service jar. There exists three configuration.xml files, one for each container type. In that XML file, we define the list of services and their init parameters that will be loaded in the corresponding container. We will see in the next paragraph that each portal instance WAR can override those default references and init parameters.

The XML schema of the configuration.xml file has changed from v1 to v2 but an easy upgrade from version 1.0.1 to version 2 is available.

Among the new features it is now possible to:

  • Use new component registration tags. We have introduced the key tag that defines the interface and the type tag that defines the implementation. Note that the key tag is not mandatory but it improves performance to reference it.


<!-- Portlet container hooks -->

  • Register plugins that can act as listeners or external plugin to bundle some plugin class in other jar modules. The usual example is the hibernate service to which we can add hbm mapping files even if those are deployed in another maven artifact.



In that sample we target the HibernateService and we will call its addPlugin() method with an argument of the type AddHibernateMappingPlugin . That object will first have been filled with the init parameters.

Therefore, it is possible to define services that will be able to receive plugins without implementing any framework interface.

Another example of use is the case of listeners as in the following code where a listener is added to the OrganisationService and will be called each time a new user is created:

      <description>this listener create the portal configuration for the new user</description>
          <object type="org.exoplatform.services.portal.impl.NewPortalConfig">
            <field  name="predefinedUser">
              <collection type="java.util.HashSet">
            <field  name="templateUser"><string>template</string></field>
            <field  name="templateLocation"><string>war:/conf/users</string></field>


In the previous XML configuration we reference the organization service and will call its method addListenerPlugin with an object of type PortalUserEventListenerImpl. Each time a new user will be created (apart the predefined ones in the list above) methods of the PortalUserEventListenerImpl will be called by the service.

As you can see there exists several type of init parameters from simple value params which bind a key with a value or more complex object mapping that fill a JavaBean with the info defined in the XML.

Many other examples exist such as for the Scheduler Service where you can add a job with a simple XML configuration or the JCR Service where you can add NodeType from your own configuration.xml file.

  • Register directly a Business Rule (drools support) into the container using the following code. That rule is then managed as any IoC loaded components and can be injected in any service.




Finally, note that each loaded service will also be dynamically loaded as a JMX MBean by the container to provide efficient monitoring. We bundle a JMX administration console as a portlet with the portal product and we will present some advanced functionalities of it in the next paragraph but here is the default view you can get for any loaded service. You can see that each service will have its method viewable and executable from the console. When an object is returned from the execution the object graph is printed so that you can get a snapshot of the service state.


  • New services


In the second screenshot of eXo directories organization, you were able to view the services/ directory with all the services. Most of them were already in the v1 but some have been modified and some have been added. Let’s have a quick overview of the new or modified services:

- The LDAP service was completely rewritten and the default library used is the javax.naming one while it was the Netscape library in version 1. That service is still used by the LDAP implementation of the OrganisationService that was also completely rewritten. This has been tested with OpenLDAP and ActiveDirectory.

- The Template Service is an important one of version 2. Indeed in version 1, the portal was built on top of Java JSF renderers that were responsible to produce the HTML. We experienced that this practice was fine for simple components that could be completely customized thanks to css classes but it happens to be a problem for larger components that people would like to customize. Therefore we have decided to delegate the rendering of JSF UIComponents to Velocity templates.

The TemplateService is then responsible of managing the velocity template loading. It is also possible to reference different type of resource loader such as the one we register for business process (BP) archive or for the JCR. Indeed in those case we allow velocity to directly parse vm files located either in a BP jar or stored in the JCR (which as the side effect to allow online modification of templates).

      <description>resource loader for the jcr</description>

In that XML configuration file we call the addPlugin() method of the VelocityService with an object of type JCRResourceLoaderImpl which extends the base class ResourceLoaderPlugin. That way you can plug your own loader mechanism to be used inside eXo templates when calling the velocity directive:


-The Database service implementation was modified to take the upgrade to Hibernate 3 into account. Moreover, in version 1.x, the platform was getting the datasource from the application server which forces to create some DS configuration XML files for each application server. This is not necessary anymore and the pooling of connection is now managed internally by the Database Service implementation.

Now you only have to define the datasource info in the configuration.xml of your portal instance such as:

        <description>JCR Workspace datasource</description>
        <property name="hibernate.show_sql" value="false"/>
        <property name="hibernate.cglib.use_reflection_optimizer" value="true"/>
        <property name="hibernate.connection.url" value="jdbc:hsqldb:file:../temp/data/jcr"/>
        <property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver"/>
        <property name="hibernate.connection.autocommit" value="true"/>
        <property name="hibernate.connection.username" value="sa"/>
        <property name="hibernate.connection.password" value=""/>
        <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>
        <property name="hibernate.c3p0.min_size" value="5"/>
        <property name="hibernate.c3p0.max_size" value="20"/>
        <property name="hibernate.c3p0.timeout" value="1800"/>
        <property name="hibernate.c3p0.max_statements" value="50"/>


In the previous sample we define a datasource for the Hypersonic database and we use c3p0 with hibernate to manage the pooling. We have tested many databases such as Oracle, MySQL, DB2, SQLServer and HSQLDB.

If you use our installer (based on InstallAnywhere), that configuration will be automatically generated for you as it also does for LDAP configuration.

-The Chart service has been upgraded from our v1 incubator code base to v2 distribution. The goal of that service is to provide convenient methods that take chart data in entry and return different types of images. The default implementation is based on JFreeChart. Here is a screenshot of one advanced view of the JMX admin portlet.

The service itself is very simple to use and abstracted from any JFreeChart class so that it is simple to swap the implementation if you prefer another library:

public interface ChartService {
 public BufferedImage createChart(Chart chart) throws Exception ; 
 public String getChartID(Chart chart) throws Exception ; 
 public BufferedImage getChartByID(String id) throws Exception ;

With Chart being a Java Bean with all the info you need to build a pie or a histogram.

-The DocumentReaderService is a service used to transform a binary file with a supported MimeType to a text. The default implementation for Microsoft Office documents is based on the Jakarta project POI, the PDF one is based the PDFBox library.

The service can be used in several places such as for allowing indexing of binary and this is exactly what we do in our JCR implementation. It can also be used to print out the text of a binary file in a portlet as we do in our ECM portlet when comparing two different versions of a file.

The interface is simple and contains a single method.

 public interface DocumentReaderService {
 public String getContentAsText(String mimeType, InputStream is) throws Exception ;


You can use the plugin mechanism described before to register your own mime type support without modifying any line of eXo code and by just dropping a jar file that contains your configuration.xml such as:

        <description>to read  the pdf inputstream</description

Which will call the addDocumentReader() method with an object of type PDFDocumentReader which implements the interface:

public interface DocumentReader {
 public String getMimeTypes() ;
 public String getContentAsText(InputStream is) throws Exception ;

Therefore the service will lookup among all the readers to see if one supports the binary MimeType and if so will delegate the text extraction to it.

- the security service has been improved to support SSO natively. The first supported SSO implementation is the Open Source project CAS from Yale University. By default there is no SSO authentication and the portal works in a standalone mode.

When SSO is enabled, the portal will not render the usual login portlet but will print out a link to delegate the authentication to CAS for the default implementation. In fact this will simply redirect the call to the cas_login.jsp file. In that JSP, we check if CAS has already granted the ticket and if it is a valid one. If this is the case we redirect to our private URL that will inform Tomcat to execute eXo JAAS login modules. If not we delegate the authentication to CAS form.

CAS is the first supported but we are working on several ones and had already custom implementation done in version 1 for ClearTrust (RSA Security) and SiteMinder (Netegrity-CA) that we will port and introduce in the distribution for v2 final.

To enable SSO you must uncomment the parameters in the following XML configuration file:

          The sso authentication method. 
          This param is used to retrieve login and logout jsp which must be named with this param
          ex : cas_login.jsp and cas_logout.jsp

When SSO is enabled you will have to configure which authentication server you want to use and that is what the parameter security.sso-authentication is for.

The portlet or any other application can get all kind of SSO information thanks to the SecurityService which has some new methods:

public String getSSOAuthentication() ;

public boolean isSSOAuthentication() ; public boolean isStandaloneAuthentication() ;

public String getProxyTicket(String userName, String urlOfTargetService)

throws Exception ;

The first three ones are obvious and the last one return the proxy ticket to forward to the third party application when you wish to launch or view one from the portal. That way the portal acts as a Proxy for all the other applications. Of course, the other applications need to be able to extract the ticket from the request and validate it directly with the authentication server. That process is generic and should be the same in most Authentication servers.

- The Remote services package is composed of a set of services used to communicate between servers located in the same network. The default implementation is based on JGroups library and is for example used by the cache service to invalidate or replicate cache entries among members of a web farm.

The main service is defined by the interface CommunicationService that manipulates simple JavaBeans such as the Message or MemberInfo ones:

public interface CommunicationService { 
 public List getMembersInfo() ;
 public CommunicationServiceMonitor getCommunicationServiceMonitor(MemberInfo info) throws Exception ;


public Message createMessage(String handlerId) ;
 public void broadcast(Message message, boolean include) throws Exception ;
 public void broadcast(Message message, ResultHandler handler, boolean include) throws Exception ;



 public PingResult ping(MemberInfo info, String message) throws Exception ;
 public List pingAll(String message) throws Exception ;


The methods are once again self-explanatory; you just need to know that each Message is associated with a MessageHandler available on each members of the cluster. And that the Message object is created by giving the handler type as an argument of the method createMessage().

Once again you can use the native plugin mechanism to add your own handler as simply as in the next XML fragment:

        <description>handle the ping request</description>

The service owns a custom advanced view in the JMX monitoring portlet where you can see each members of the network and monitor the status of all the Message Handlers as shown in the next screenshot.

  • Upgrade mechanism

Upgrading from version 1.x to version 2.x is a hot and complex topic. Indeed, we need to upgrade all type of data such as users profiles, pages, navigation nodes or forum entries either it is stored as normalized elements or XML documents in DB tables or as entries in LDAP servers.

To manage such a task, we have rewritten the Backup service for version 1.0.1 and 2.x so that data exported with version 1.0.1 will be understood by the backup service of version 2 for a smooth import upgrade.

Therefore, if you wish to upgrade an eXo Platform v1 in production you will first have to install the version 1.0.1. That installation should be simple and all the Data Sources should work the same as in v1.0 as the data structure is the same.

Then you will need to use the associated portlet or if you want to do it programmatically the ImportExportService interface to import and transform the v1.0.1 structured data into v2.x structured one.

The next screen shot show the UI portlet in v2.x version.

The mechanism behind the scene is in fact quite simple but not easy to implement and test. The idea is to provide information on the version of the data structure your export and for that purpose we define a metadata.xml file bundled with the data itself in the exported zips.

<?xml version="1.0" encoding="UTF-8"?>
<object type="org.exoplatform.services.backup.Metadata">
<field name="description">
<string>Export the organization data</string>
<field name="version">


Therefore, when the data will be upgraded, the new version will be able to get the version number and to provide the modification by removing the unused values, modifying or adding some default ones for add XML tags for example.

  1. The Portal

The new Portal version is 1.1 and relies on eXo Platform v2. It includes several new features but we mainly focused on improving ergonomy, accessibility, monitoring, security and web design of existing functionalities.

In this chapter, we will review all those improvements and new features but we will start by explaining how the service configuration and init parameters, we introduced in previous chapter, can be overridden in each portal instance.

  • Leveraging the platform architecture and overriding default configuration in your portal instance

- That default information can be overridden from the portal WAR thanks to a configuration.xml file located under WEB-INF/conf/. Therefore, each portal WAR can define its own set of business services to be loaded as well as their init parameters.

A real example of the power of that architecture can be seen with two portal instances hosted on the same server. One must use a LDAP while the other must rely on a DB for storing the user, their roles and the groups they are in.

To model the company organization, we provide a service called the OrganizationService thanks to an API that is a set of interfaces and Value Objects. That service describes the set of users, their properties but also the roles they get (we call that memberships) in a group. For that service, we provide two default implementations one based on a database and the other based on LDAP (OpenLDAP and ActiveDirectory have been tested). Many services depend on the organization service like the Portal service that needs it to check the permission a user may need to access a portal page. Of course the Portal service only interacts with the OrganizationService API and the IoC container injects the real implementation by looking for it in the PortalContainer. Hence, by changing the loaded implementation you will change the OrganizationService backend store but that will not impact your Portal service. Thus, with two portal WARs it is possible to configure one instance to use a LDAP backend while the other instance will use the DB backend.

- Another useful feature of the core platform is the SessionContainer. As soon as a request for a new user arrives on the server, the portal delegates the creation of the SessionContainer to the core platform. That session object will then be shared among all the portlets of the portal for a the lifetime of the user session. That way we enable a new mode, not defined in the portlet specification, to share objects between portlets application wars while the spec only allows object to be shared among portlets in the same WAR.

<rule name="Check Public Access">
    <parameter identifier="fact"><class>RequestFact</class></parameter>
    <java:condition>fact.getAccessLink() == RequestInfo.PUBLIC_ACCESS</java:condition>
    <java:condition>fact.isNewRequest() || fact.isChangePortal()  || fact.isChangeLink()</java:condition>
      if(fact.verifyPublicPortalAcess())  {
        fact.newPortalSession() ;

The same type of rules are defined in the same DRL file when accessing a private portal or when accessing a private portal while being an admin user - that is called admin mode and it is quite useful to check user modifications without having to know its password. The next screen shows the “Portal Admin” portlet that allows the admin to load user portal context with full rights. That technique is also used when configuring communities (we will come back to that a bit later).

Several other uses of Business Rules are currently experimented such as the way to bind a rule to a page component (container or portlet) to analyze - based on custom conditions that can for instance be the existence of a service - either or not the component should be rendered.

  • Accessibility: WCAG 1.0 and US 08 section

This is probably the most complex and time-consuming refactor we had to do. To make it quick, the w3c foundation has released the Web Content Accessibility Guidelines (WCAG 1.0) specification that defines a set of guidelines to follow to make the rendered HTML readable by software dedicated for people with disabilities. The US federal requirements known as the US 508 section is very close to WCAG.

As an example the specification requires that the HTML only contains tags of the type <div> and <span> for managing the page layout and to avoid the use of table for that case. But version 1.0 was fully built using JSF renderers that were producing layouts based on tables. Therefore we had to rewrite (we did it at the same time as we created the velocity templates for JSF renderers) all the renderer code and make them use div and span tags. But that also had a large impact on css classes that we were also extensively using. All in all that was a long and tough work to make nice layouts that work on all modern browsers and that are WCAG and US 508 compliant.

The next image is a screenshot taken in Firefox that use the web developer plugin extension and allows us to outline the block area in a page. As you can see every layer is now a block and that for any page of the different product sites.

  • Monitoring

The version 1 already provided an extensive set of monitoring tools. Version 2.x goes even deeper and takes advantage of the Chart Service that was introduced in the previous chapter.

Furthermore, as we said explained each service that is loaded in the Service Container is exposed as a JMX MBean in a MBeanServer and we provide in eXo Platform v2 a JMX portlet to monitor the service state. Each service is viewable through a standard view but it is also possible to add an advanced view.

We will now have a quick overview of some of the advanced JMX view. We now provide:

- The cache monitor allows you to view all the cache entries, either in a table or thanks to the Chart Service in a histogram.

- The logging advanced view allows us to monitor the log service. Indeed, we have added a server layer between the client and the usual file log and it is now possible from the JMX portlet to view the log info and to configure the log levels (info, debug, trace or error) directly from the portlet as shown in the next screenshot.

- The user and portal activities monitors. Those screens are probably the most useful one we introduced since version 1.x. We already shown a screenshot that presented a chart with the number of hit a portlet got (either it was a process action or a render portlet URL call).

The next screen shows several critical information about the number of hits a portal can get as well as the response time and the number of errors that were raised. As you can see there exist a form that allows filtering the information so that we can focus on a certain period of time or amount of time. It is also possible to monitor the information for a page or for a dedicated portlet and to generate the charts for them.

Therefore, it is possible to capture portal usage metrics that includes the most visited pages overall, the most visited pages in last 24 hours, and the most used portlets.

All the other monitors, those were available in version 1 such as the JVM monitor, the user session one or the portlet container status have been upgraded to be part of the advanced JMX console.

  • Ergonomy: Navigation edit mode and Drag And Drop

Portal Version 1.1 comes with many improvements regarding usability.

The major differences come from the edit modes: edit portal template, edit navigation tree and edit page modes.

Remind that in version 1 we had the left column that was showing the navigation tree and was also containing the edit mode icons when the user is logged in (more or less icons according to the user rights) as shown in the next screen.

The first work was to split the menu and the edit mode icons in two different portlets in order to build portals with no navigation left columns. That means we also now provide a multi navigation level horizontal menu to be able to reach any node from it while in version 1 the menu was only able to render the navigation tree up to the second children level.

The next screen shows the new edit mode portlet. It is only viewable once the user is logged in. The 3 icons are the same as in version one; from left to right, we have the edit portal template mode, the edit navigation tree and the edit page mode.

Of course, the edit portal template icon does not appear when the user is not responsible of the portal template. That is the case when the user is part of a community that is used to provide a single template (with banner, footer and navigation portlets) for all the member of the same group.

The edit portal template mode does not change much from version 1. Just a few concepts have been introduced to manage global Theme and we will come back to it when we will talk about the web design issues. Its goal is to enable the user to change the portal layout thanks to a WYSIWYG online tool.

Any type of layout is doable thanks to our dynamic approach based on JSF component tree. This is a big difference with most other portal solutions that rely on a finite set of static templates to manage their layouts.

As you can see in the next screenshot, the portal template (that is also the case with the edit page mode) is composed of nested containers that also wrap portlets. The containers are responsible for rendering their children in rows, columns or tabs.

One major improvement in version 2 is the support of Drag & Drop that allows the user to drag containers (and therefore all the components sub tree) or portlets from one place to another. Here again that functionality overcomes all the other portal solution that only drags portlets from one place to another inside a static template while in eXo Portal you can drag a column or a set of columns and rows from one place to another. Also note that this feature is more than just a toy as it is now possible to move a portlet outside its container while in version 1 we had to delete the previous one (and all its preferences) and recreate it somewhere else.

The main problem we faced when splitting the menu portlet and the edit mode portlet was the fact that when a user clicked on the edit navigation tree mode we were decorating the menu nodes with some action icons to enable navigation modifications. It was therefore possible to add, edit, remove and move a node (only in the same navigation level) as shown in the next screenshot taken from the online eXo documentation.

Version 2 introduces a completely different model for managing navigation tree as now, when a user clicks on the navigation tree icon he will be able to get a full tree of nodes and will be able to expand and collapse them as he desires. Furthermore, it is now possible to move nodes from one location level to the other by copying it.

The next screenshot is what a user can now see when he clicks on the “Show Navigation” icon.

From there one can add, edit, copy, paste, move and delete a node.

Remind that a node is simply a pointer to a portal page (portlet aggregation) and that a page can be pointed by several nodes (it is even possible to point a page that is owned by another user if he made it public), in math semantic we would call that a surjection.

Therefore, the process to add/edit a node is simply defining the page binding and some Meta-data such as permissions (edit and view ones that we will describe more in the security section a bit later) or display name as shown in the following screen.

Note that the mobile support works exactly like in version 1 where xHTML-MP was already supported.

The previous form also contains the visible check box that can be used to tag a node so that it will not appear in the navigation portlets but will still be reachable from the URL.

  • Security and enhanced community management

Security is the core concept of a collaborative portal platform.

In version 1 the security granularity to view or edit pages, nodes and portals was restricted to the owner or all users.

In version 2 the granularity is finer as it is possible to define permissions that check if the user who requests the resource has the correct membership in a group. Therefore, it is for example possible to protect a portal, navigation tree or page when an identified user tries to reach another user portal. That was it is possible to define memberships and groups of people that can access some critical information while the other one won’t be able to reach.

The portlet permissions defined in portlet registry now use membership and therefore only people with the correct membership in a group will be able to add the portlets in their page.

The community concept has been improved too. Remind that a community is a special customized group that allows any user that is part of the community to import some portal pages and/or the portal template defined by a portal that is binded to the community as shown in the following drawing.

In version 1, the community support was limited and it was not yet possible to:

  • Allow some members of a group to edit the portlet preferences (thanks to the edit mode) for the group and only the admin was allowed to do it
  • Rank the community navigation tree that are mounted in the user own navigation tree so that the order in the navigation portlet is predefined
  • Force the home page of a user that is part of a portal community to be the one of the binded portal.

All those features are now available in version 2 and the next screenshot introduces the configuration page for the two community types (portal template and community one). As you can see the portal community now has a “Default Home Page” property and the navigation community has a “Priority” one.

  • Web design

As you can see with the screenshots, we focused more on the web design for version 2.

The main reason is strategic as the first version was mainly targeting ISV and VARs that anyway had to change the web design. With version 2 we also target end users that may not change the default themes.

As we already said in a previous section, any type of layout is doable with eXo Portal thanks to nested containers and portlets. Each one of those components can get a dedicated decorator and css syle. As an example you can see the next screenshot, which will be the home page of our new corporate web site built on top of eXo. The layout and the skins are quite different from the previous pasted images.

Version 1 skin mechanism that is coupled with the layout functionality is very powerful as it allows any components of the page to have its own style. Nevertheless, in most cases such a feature is not necessary and the support of a global theme functionality, which allows the swap of color or basic icons, is also needed.

That is why we have enhanced our local mechanism with a global one and made them work together. Indeed, the root of the component tree – which is the portal root – will have a theme property. Each sub component will inherit that property to select the correct decorator and style (remind a component is either a container or a portlet). Now to allow the v1 local skinning, we allow components to override the global theme with a local one. If the component is a portlet then it means it has a custom style that a change of global theme will not impact. If it is a container then its style will change but that will be also the case of its sub components. Therefore we introduce the notion of local-theme. That way it possible to have sub part of a page that have their own style that would not be impacted by a global theme change as in that case the sub area will not inherit the global theme but will use its local one.

In Part 2 of this article, we will introduce the JCR specification and our own eXo JCR implementation as well as our new ECM product and the incoming eXo BI and eXo groupware. Stay tuned…

public Object send(MemberInfo dest, Message message) throws Exception ; - We also have seen in last chapter that a Drools Business Rule could be injected in the service container and we would like to introduce a use case. Indeed, using rules is interesting when a lot of conditions need to be checked before an action is launched. That is typically the case in a portal when you have to load a user context and have several info to check to launch the correct configuration. In version 1.1 of the portal we have extracted that logic from Java code and placed it in several Business Rule. The next XML fragment shows one of the rule that check if the requested URL is a public one as well as if the user is a new one or several other conditions.

Dig Deeper on Modular containers

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.