Posts Tagged GateIn

Your first Juzu portlet

Juzu ?

Juzu is a Buddhist prayer bead. One sentence and I am sure you have already learnt something, impressive no? 😉

Ok, I won’t speak about Buddhism here.
Juzu is also a new framework for developing portlets (and standalone applications soon) very quickly. You can find all the information you need on the Juzu website.

Now let’s create our first portlet with Juzu !

Creating a new project

Juzu comes with a maven archetype. We can use it to quickly create our first application :

mvn archetype:generate \
   -DarchetypeGroupId=org.juzu \
   -DarchetypeArtifactId=juzu-archetype \
   -DarchetypeVersion=0.5.1 \
   -DgroupId=org.example \
   -DartifactId=myapp \

This creates a juzu project in a myapp folder.

Deploying the Juzu portlet

Before deploying the application, you need to build it.
Simply run mvn clean package in the myapp folder. It will generate a myapp.war under your myapp/target folder.

We are now ready to deploy the portlet in a portal container. We will use the latest GateIn release (3.4), the tomcat bundle version. Once downloaded, install it by unzipping it in the location of your choice.

The only thing you need to do is to drop the myapp.war file in the webapps folder, and start GateIn with bin/ run.

Once started, add your portlet in a page. You should see :

Great ! You just finished your first Juzu portlet !

Let’s explore the project before enhancing it.

Exploring the project

The project structure looks like this :

The mandatory web.xml is there. It does not contain anything.


The archetype generates a basic portlet.xml with some juzu init parameters :

<?xml version="1.0" encoding="UTF-8"?>
<portlet-app xmlns=""
     <display-name xml:lang="EN">Juzu Sample Application</display-name>
       <title>Sample Application</title>

The portlet-class is the generic Juzu portlet class juzu.portlet.JuzuPortlet.
This class declares 2 init parameters :

  • juzu.run_mode
    • dev : changes made on source files are automatically hot recompiled and reloaded, so you don’t need to redeploy your application to test them. This is a real productivity boost while developing an application !
    • prod : “classic” mode, where you need to recompile and redeploy your application to apply your changes.
  • juzu.inject – defines the inject implementation. Two implementations are currently supported : weld (CDI Reference Implementation) and spring.

The Juzu portlet class uses the file to gather needed extra information.

The portlet.xml file also contains basic information about the portlet : portlet-name, display-name and portlet-info. You can change them or add some others if needed.

This file contains all the configuration of the application.
The file allows to activate plugins, add JS/CSS resources, … but let’s keep it simple for now.
The only mandatory configuration is the declaration of the application, thanks to the @juzu.Application annotation. You have to declare the base package of your application, in our case org.sample.

This class is a Juzu controller. It is composed of a view method index (annotated with @View) which allows to render the index template.
The path of the index template is set with the @Path annotation. By default, Juzu uses the templates package of the application as its root path. So in our case, the template is located at org/sample/templates/index.gtmpl.

Switching to dev mode

Now that we know a little bit more about what is a Juzu application, let’s improve a little bit our basic helloworld application.
First of all, we will switch from prod to dev mode, in order to quickly test our changes. For that, edit your portlet.xml file and change the value of the init-param juzu.run_mode to dev. Then build your application and drop the war in the webapps folder of GateIn. Here you don’t need to stop/start GateIn as the webapp will be automatically redeployed.

As we did not change anything in the source files of our application, you should see the same “Hello World” message in your portlet.

In order to test the dev mode, you can for instance rename the file webapps/myapp/WEB-INF/src/org/sample/templates/index.gtmpl to index2.gtmpl. After refreshing your page, you will get the following message :

Now edit webapps/myapp/WEB-INF/src/org/sample/ and change

Template index;


Template index;

and refresh your page once again.
Everything back to normal ! Pretty cool, isn’t it ? 😉

Forms, Actions and type safe template parameters

We will create an application which displays the map of the location choosen by the user.
Firstly, update your index.gtmpl template :

#{param name=location/}
#{param name=mapURL/}

Location :
<form action="@{updateLocation()}" method="post">
	<input type="text" name="location" value="${location}"/>
	<input type="submit"/>
<%if(location) {%>
<div id="map">
  • #{param name=location/} and #{param name=mapURL/} declares 2 type safe template parameters which will be used latter in our Controller
  • the form contains a input text, and submit to our juzu controller action updateLocation
  • finally, if a location is specified, the maps is displayed

Now, let’s update update our :

package org.sample;

import juzu.Action;
import juzu.Path;
import juzu.Resource;
import juzu.Response;
import juzu.View;
import juzu.template.Template;

import javax.inject.Inject;
import java.util.HashMap;
import java.util.Map;

public class Controller {

  org.sample.templates.index index;

  public void index() throws IOException {
    index("", "");

  public void index(String location, String mapURL) throws IOException {

  public Response updateLocation(String location) throws IOException {
    String mapURL = "" + location + "&aq=&t=m&ie=UTF8&hq=&hnear=" + location + "&z=12&output=embed";

	return Controller_.index(location, mapURL);
  • the index template is now of type org.sample.templates.index. This class is generated thanks to the annotations, and is a subclass of Template. Using this specific type will allow us to leverage declared template parameters, location and mapURL in our case.
  • the default index View now calls a new index View which accepts the location and mapURL arguments. This new view uses the index template class and its fluent syntax (do you like it ? Personnaly I do ;)). Thanks to the declaration of the location and mapURL parameters in the template, the org.sample.templates.index template class accepts a location method and a mapURL method to set their values.
  • the updateLocation method is defined as an action thanks to tthe @Action annotation. It is called by the form to retrieve the correct URL (building the map URL is a basic example, generally you will call your services here). Then it redirects to the index View method in order to render the index template. Note the _ at the end of the Controller name. The class Controller_ is the “annotations processed” version of the Controller class.

If you did all these changes in the deployed version of your application (in webapps/myapp), you just need to refresh, and you should be able to enter a location and then see the corresponding map :


Juzu provides some ease to use Ajax in your application. We will use them to avoid reloading our page when submitting a new location in our form.
The Ajax plugin needs JQuery. We can add it to our application by simply dropping the JQuery js file in the project and declare it in the file with the Asset plugin (I dropped the JQuery js file in public/scripts) :

	scripts = {
			id = "jquery",  
			src = "public/scripts/jquery-1.7.1.min.js")

We will now update our controller in order to add a new method which will only provide the map URL :

  public Response.Content<Stream.Char> getMapURL(String location) throws IOException {
	String mapURL = "" + location + "&aq=&t=m&ie=UTF8&hq=&hnear=" + location + "&z=12&output=embed";

	return Response.ok("{\"mapURL\": \"" + mapURL +"\"}").withMimeType("application/json");

Note that this new method is not annotated with @Action anymore. Annotating a method with @Ajax will make it accessible for Ajax calls. The @Resource annotation makes this method send the entire response to the client. That’s what we want as this method simply creates the new URL and sends it back to the client as a JSON response.

Finally, we have to update our template file to add the Ajax call :

#{param name=location/}
#{param name=mapURL/}

function submitLocation(location) {
		url: "Controller.getMapURL()",
		data: {"location": location}
	}).done(function(data) {
		$('#map > iframe').attr('src', data.mapURL);
	return false;

Location :
<form onsubmit="return submitLocation(this.location.value)">
	<input type="text" name="location" value="${location}"/>
	<input type="submit"/>

<div id="map">

The submission of the form now calls the submitLocation javascript function. This function uses the juzu Ajax function jzAjax (which uses the ajax JQuery function under the hood). This function calls the URL provided in the url param with the parameters provided in data. So here it will call the newly created method of our Controller and receive the new map URL in JSON :

{"mapURL": ""}

Then we just use JQuery to update the map.

Once again, simply refresh your page to see it in action !

You can now learn more on Juzu by going to the website or watching the screencasts.


, , ,


JSF 2 / RichFaces portlet in eXo (Part 2/3) : Content Management integration

eXoPlatform comes with powerful content management features and a large set of portlets to use these features. However you may want to use these content management capabilities in your own portlets.
This second tutorial will learn you how to use eXo Content Management API and portlets to create a sample store application. The first part about JSF / RichFaces integration is available here.
This application will expose a list of products with related pictures. Each product will be composed of a name, a description, a price, a thumbnail and some pictures. The thumbnail and the related pictures will be retrieved from the eXo Content Management.
The page will display the product’s thumbnail and the product’s caracteristics. The related pictures will be available by links. A Content Detail portlet will be used to display each related picture.

The source code of this tutorial is available here.

Adding contents

In order to easily retrieve the contents, they should be organized correctly. Under the root folder (let’s say repository:collaboration:/sites content/live/acme/documents/products), a folder will be created for each product, named with product’s id. All the product related contents will be stored in the corresponding folder. The thumbnail will also be stored in the product’s folder, but with the special name “thumbnail” to be able to distinguish it from the others pictures
So the contents tree will looks like this :

Instead of creating all these contents by hand, you can download this JCR export. To use it :

  • go to the Content Explorer
  • select the Sites Management drive
  • go to acme > documents
  • click on the System tab
  • click on the Import Node button
  • select the export file for the Upload File field
  • click on Import

 To be sure that all contents are in published state, you may need to republish them.

Adding eXo dependencies

The first step is to add the eXo dependencies that will be used in our portlet. Edit your pom.xml and add these lines :


Using eXo Content Management API

In order to manage data displayed in our page, we need a managed bean :

public class ComicsStoreBean implements Serializable {

    private static final long serialVersionUID = -6239437588285327644L;

    private ContentService contentService;
    private ProductService productService;

    private List<Product> products;

    public ComicsStoreBean() {
        PortletPreferences prefs = ((PortletRequest)  FacesContext.getCurrentInstance().getExternalContext().getRequest()).getPreferences();
        String contentsRootPath = prefs.getValue("contentsRootPath", "");

        contentService = new ContentServiceImpl(contentsRootPath);
        productService = new ProductServiceImpl();

    public List getProducts() {
        if(products == null) {
            products = productService.getProducts();

            for(Product product : products) {

        return products;

This bean instantiates 2 services : one for the products (ProductService), one for the contents (ContentService) which is initialized with the root folder in the content management system of the contents used in the store (retrieved from a portlet preference).

The bean exposes only one data, the products, via the getProducts method. This method calls the ProductService object to retrieve all the products. The ProductService class simply returns sample products :

public class ProductServiceImpl implements ProductService {
    public List getProducts() {
        List products = new ArrayList();
        products.add(new Product(1, "Ironman", "Ironman", 12));
        products.add(new Product(2, "Wolverine", "Wolverine", 15.5));
        products.add(new Product(3, "Spiderman", "Spiderman", 13));
        products.add(new Product(4, "Thor", "Thor", 10));
        products.add(new Product(5, "Hulk", "Hulk", 11));
        products.add(new Product(6, "Captain America", "Captain America", 15));
        products.add(new Product(7, "Human Torch", "Human Torch", 11));
        products.add(new Product(8, "Magneto", "Magneto", 17));
        products.add(new Product(9, "Dardevil", "Dardevil", 16.5));
        return products;

Then the managed bean calls the ContentService object to retrieve the contents related to the products. Here is the most interesting part as it deals with eXo Content Management.
ExoPlatform provides an API to interact with all content management capabilities (contents, taxonomy, links, publication, SEO, …). In our sample application we will use the WCMComposer API which allows to work with contents.

Exo Content Management provides an utility method to easily instantiate a service :

WCMComposer wcmComposer = WCMCoreUtils.getService(WCMComposer.class);

This service is used in the 2 methods of ContentService : getProductThumbnailPath and getProductPictures.
The getProductThumbnailPath method returns the path of the thumbnail of the product if it exists :

public String getProductThumbnailPath(int productId) {
    String thumbnailPath = null;

    // get wcmcomposer service
    WCMComposer wcmComposer = WCMCoreUtils.getService(WCMComposer.class);

    HashMap filters = new HashMap();
    //filters.put(WCMComposer.FILTER_LANGUAGE, Util.getPortalRequestContext().getLocale().getLanguage());
    filters.put(WCMComposer.FILTER_MODE, Utils.getCurrentMode());
    // take the last published version
    filters.put(WCMComposer.FILTER_VERSION, null);

    try {
        Node productThumbnailNode = wcmComposer.getContent(workspace, path + productId + "/thumbnail", filters,
        if (productThumbnailNode != null) {
            thumbnailPath = path + productId + "/thumbnail";
    } catch (Exception e) {
        thumbnailPath = null;

    return thumbnailPath;

The getContent method of the WCMComposer API is used here. It allows to retrieve a content based on its path. Some filters can be added to select the right content base for instance on its language, its version or its publication state.

The getProductPictures method returns all the contents related to a product :

public List getProductPictures(int productId) {
    List pictures = null;

    // get wcmcomposer service
    WCMComposer wcmComposer = WCMCoreUtils.getService(WCMComposer.class);

    HashMap filters = new HashMap();
    // content of the currently selected language
    //filters.put(WCMComposer.FILTER_LANGUAGE, Util.getPortalRequestContext().getLocale().getLanguage());
    // live or edit mode (will respectively get draft or published content)
    filters.put(WCMComposer.FILTER_MODE, Utils.getCurrentMode());
    filters.put(WCMComposer.FILTER_VERSION, WCMComposer.BASE_VERSION);
    // order clauses
    filters.put(WCMComposer.FILTER_ORDER_BY, "exo:dateModified");
    filters.put(WCMComposer.FILTER_ORDER_TYPE, "ASC");

    try {
        // service call to retrieve the contents
        List picturesNodes = wcmComposer.getContents(workspace, path + productId, filters,
        pictures = new ArrayList();
        for (Node pictureNode : picturesNodes) {
            // exclude thumbnail
            if (!pictureNode.getProperty("exo:name").getString().equals("thumbnail")) {

                // In live mode, the last published version is a frozenNode, so
                // we need to get the node referenced by this frozen to get the real path
                String picturePath = null;
                if (pictureNode.isNodeType("nt:frozenNode")) {
                    String uuid = pictureNode.getProperty("jcr:frozenUuid").getString();
                    Node originalNode = pictureNode.getSession().getNodeByUUID(uuid);
                    picturePath = originalNode.getPath();
                } else {
                    picturePath = pictureNode.getPath();

                Picture picture = new Picture(pictureNode.getProperty("exo:name").getString(), picturePath, pictureNode.getProperty("exo:title").getString());
    } catch (Exception e) {
        pictures = null;

    return pictures;

We now use the getContents method, the equivalent of getContent but for multiple contents.
One really interesting point is that by using this API you can profit from all the eXo Content Management features. For example, by calling the getContents method with the filter WCMComposer.FILTER_VERSION set to WCMComposer.BASE_VERSION and the filter WCMComposer.FILTER_MODE set to the current mode (live or edit), only the link of the published pictures will be visible in live mode whereas link of pictures in draft state will be visible in edit mode.

As you can see, the node’s type is checked to distinguish the frozenNode case :

if (pictureNode.isNodeType("nt:frozenNode"))

In fact, a frozenNode is a published version of an original node. A frozenNode references the original node (in our case, the picture node) through its jcr:frozenUuid property. So we need to get this property to retrieve the original node and get its path.

The last part is to edit our JSF pages to display all the products. For so, a RichFaces data grid (rich:dataGrid) is used :

                <rich:dataGrid value="#{comicsStoreBean.products}" var="product" columns="3" elements="6" width="600px" border="0">
                    <rich:panel bodyClass="pbody">
                        <f:facet name="header">
                            <h:outputText value="#{}"></h:outputText>
                        <h:panelGrid id="product" columns="2" columnClasses="productThumbnailColumn, productDetailColumn">
                                        <h:panelGroup rendered="#{not empty product.thumbnailPath}">
                                                <img src="/rest/jcr/repository/collaboration#{product.thumbnailPath}" width="80px"></img>
                                <h:panelGrid columns="2">
                                     <h:outputText value="Description:" styleClass="label"></h:outputText>
                                     <h:outputText value="#{product.description}"/>
                                     <h:outputText value="Price:" styleClass="label"></h:outputText>
                                     <h:outputText value="#{product.price} €"/>
                                     <h:outputText value="Photos:" styleClass="label"></h:outputText>
                                     <ui:repeat value="#{}" var="picture" varStatus="status">
                                        <h:outputLink onclick="window.location = window.location.pathname + '?content-id=/repository/collaboration#{picture.path}'; return false;" value="#">
                                                <h:outputText value="#{picture.title}"></h:outputText>
                                        #{status.last ? '' : ' | '}
                        <div class="buyButtonDiv">
                                <h:commandButton value="Buy" styleClass="buyButton"></h:commandButton>
                    <f:facet name="footer">

The ui:repeat lists all links towards the product’s pictures. The link simply goes to the same page (because a Content Detail portlet will be added in this page) and pass the content-id parameter with the path of the content to display. The Content Detail will just look at this parameter and display the targeted content.

Adding Content Detail in the page

In order to display the products’ pictures we need to add a Content Detail portlet in the page :

  • edit the page (Edit > Page > Layout in the top bar)
  • in the portlet catalog, open the Contents category
  • drag and drop a Content Detail portlet on the page, under the first portlet
  • edit the portlet
  • select a default content for the Content Path field (products/Comics)
  • scroll down the preferences screen and click on the Advanced link
  • choose Enabled for the Contextual Content field
  • leave the other field as default (by content-id)
  • click on Save
  • click on Close
  • click on the Save icon (upper right) to save the modifications done to the page

Our store is open !

Let’s play with it.
Click on a picture link, for instance the Photo 1 of Wolverine :

The picture is now displayed below.
Let’s now add a new picture. To do so :

  • go to the Content Explorer
  • go to the Ironman folder (acme > documents > products > 1)
  • click on the Upload FIles button
  • select your file
  • click on Save

The picture is now uploaded. Leave it in draft state and go back to the Comics store page. As you can see, your new picture does not appears in the Ironman’s pictures.
Now switch to edit mode by clicking on Edit > Content.

The picture link now appears and you can click it to display the new picture. Up to you now to publish it to make it available in live mode.

This tutorial showed how to use the eXo Content Management API to profit from all the eXo Content Management features inside your own portlets.
Don’t hesitate to take a look at the documentation to discover all the available APIs. Enjoy !

, , , ,


Request parameters from a portlet in eXo/GateIn

Portlet specs does not provide a standard way to read a parameter from the request within a portlet, for example to get the myparameter parameter in http://localhost/portal?myparameter=myvalue.

request.getParameter() within a portlet does not help since the request object is a PortletRequest, not the HttpRequest.

An easy solution in eXo/GateIn is to use the getRealRequest method of the concrete implementation of PortletRequest of GateIn. So, in order to retrieve the myparameter param from the request in the render phase, you can do :

((org.gatein.pc.portlet.impl.jsr168.api.RenderRequestImpl) request).getRealRequest().getParameter("myparameter")

, ,