Skip navigation


I will give a BOF at JavaOne 2006 entitled "Portlet development best practices".


The Portlet specification allows people to create portable components for portals. It offers an API that allows developers to create personalized content for end users. This session aims to teach about how to develop a portlet that is a good citizen of a portal and how to leverage the Portlet API at its best.


I don't know yet how this BOF is going to be. In the past I had many occasions to be a speaker during events such as JBoss World or JavaPolis but this is the first occasion I have to give a BOF.


In order to prepare and promote this event I am gathering input from the Portlet community and I would like to know what people would like to learn and talk about. The most appropriate places to discuss about this are the group that I created on the JavaOne Conference site and that topic on our forums for those who don't go at JavaOne but still wants to discuss about it.

Latest JBoss Portal developments : JBoss Portal 2.0.1 RC1


Thanks our numerous contributors we have been able to release the first release candidate of JBoss Portal 2.0.1 which is the first maintenance release of the 2.0 branch. This release adds new new features and fixes a few bug.

Forums improvements


A lot of work has been made here :

  • Navigation improved
  • The normal state shows the list of the 5 last posts and is configurable, can be the last populars, etc...
  • Poll implementation
  • Personalization : signature, notify on reply, number of topics per page, date format, post order, etc...

Hibernate Slide store implementation


The Content Management System of JBoss Portal uses Slide as a back end storage. The Slide service then delegates to something called store the responsability of storing nodes. The default implementation uses a file system and has some drawbacks. The first one is the very poor scalability in a concurrent environment, the second one is that it simply does not work in a clustered environment (don't tell me to use a shared file system), the last one is that it uses the file system itself and not a database.


So I tried to use the JDBC or J2EE store implementation that delegates to a database and here again I am not happy with it. While it solved the scalability problem it raises the portability issues. The store implementations are specific to databases, for instance you have one for MySQL, one for Postgresql, etc... The other issue I have with it is that the way it gets the datasource in a J2EE environment assumes that you are running it from a servlet thread. While it may be true most of the time sometimes the store is called from a service thread.


We solved the previous points by developing our own store implementation based on hibernate which is highly configurable and provide portability accross many databases. Also we did a standalone release that I call JBoss Slide that integrates Slide in JBoss in the best way possible and provide also an implementation of cache invalidation which uses JBoss clustering under the hood featuring things like auto discovery (in the default Slide clustering, you have to hardcode the list of the other cluster nodes in each node) and configurable invalidation transport (JMS or IP multicast).


By the way if someone has access to the Slide Wiki, that would be a good idea to put a link to the JBoss Slide page.

Bug fixes


Every release has its bugfixes, it's boring to list them all so please consult jira for more infos.



In conclusion, this is an important release, yet we are working very hard on releasing JBoss Portal 2.2 (scheduled for November 05) which will add more exciting features (I coded over the weekend an implementation for Portlet session replication for instance). To hear more about JBoss Portal 2.2 and how we implement it, I will give a talk at JBoss World Barcelona, October 10-12. I would be pleased to meet anybody to talk about portals.

Julien Viet

The recurring interportlet communication dilemna

First the we need to shorten the name "interportlet communication", I propose IPC.

Often people on our forums talk about IPC. The thing is that this is always ambigous in the sense that they are not talking about the same thing. After all what is the exact meaning of the term ? It loosely means that portlets communicate between themselves. Well if you read the JSR 168 specification it is obvious that the component model they have built works isolated, meaning that a portlet has access to information about itself or can trigger events that will affect itself.

So you can see on our forums conversations that looks like :

- we absolutely need IPC

- what if you put the object in the application scope of the session

- what do you mean ? I want to provide a link to another portlet

- ahhh.... ok sorry

It shows that people need IPC, because in the real world portlet never work alone and they need to exchange some kind of information. But before IPC, before all they need names to have non ambiguous conversations. Even internally we have the same issues, for instance here is an excerpt of my IM conversation with Roy :

julien: why do we need to talk with Ben ?

julien: I don't see the reason

roy: we should tap him for ipc too, no?

julien: IPC ?

roy: no

julien: it should be possible to do it without JBoss Cache using some tricks with the HTTP session replication (which uses JBoss Cache under the cover)

roy: then we dont talk to Ben

roy: most vendors have their own api for ipc

julien: it depends what you call IPC

julien: they have IPC API for events

julien: not attribute session sharing

roy: this seems to be the ipc that people want... not the session hack

julien: or for do cross linking

julien: so what do you call IPC ?

julien: at the end perhaps we don't speak the same language

roy: portlet A action triggers reponse in portlet B

julien: yes

roy: yes. i speak spanish, u speak french.

julien: JBoss Cache is not going to help you doing cross linking

julien: JBoss Cache replicates object

roy: implementing cache, couldnt you get all the above forms of IPC to work?

julien: it does not make linking

julien: we really need to define a language

julien: let's define

roy: we need to define ipc

julien: IPC/xlink

julien: IPC/event

julien: IPC/session

You see what I mean ? I am a big fan of naming concepts, so then people can refer to it with a simple name. It is how we started to put names on those concepts.


So far from my personnal experience, I have seen three forms of IPC :

  • IPC/session : portlet sharing objects, this is possible today by using the PortletSession provided during the request and using the application scope. However there are limitations in the sense that the portlet need to be bundled in the same application to be capable to share objects.
  • IPC/xlink : A portlet provides a link to another portlet : this is not possible today. I have a hack in mind to resolve that but this is really an hack that should work with any container :-) .
  • IPC/event : A portlet is capable to create events that are consummed by other portlets.
I don't pretend to know all the form of communication between portlet, perhaps I am missing some others.


Finally in our case the firts conversion could have looked like :

- We need IPC/xlink

- ok, why don't you try IPC/session rather ?

- no it is not what I need

- ahhh... ok sorry

Ok the conversation ended up the same but at least the second guy did not look stupid.


My colleague Tom Bayens, project lead of jBPM, asked me questions regarding the web frameworks and the portlet specification. This has been debated at Javaone with the web frameworks smackdown and Stan Silvert presented a session on JSF and portlets.


The questions Tom asked were :



  • what is your take on portlet versus webframework ? if it takes some time for the webframeworks to support portlets, there must be some gap or mismatch between them.
  • do portlets need a separate framework or do you think that plain webframeworks can add satisfactory support for portlets ?
  • another question is how limiting is writing a webapp to a bridge so that the same webapp can be used as webapp and as portlet. will this become mainstream ? or will this never be possible without serious limitations




I am not capable to give a full comparison matrix of all the frameworks, however I can talk about what I know : interraction with a portal and I can extend on JSF and struts.


If the web frameworks want to evolve in the portlet market, they must adapt to the portlet environment and there are mismatches :

  • protocol mismatch : how the interractions occurs, the portlet defines a two step protocol with a clean separation between the phase where you perform an action and the phase where you render the portlet. In my opinion it is one of the best thing of the portlet specification.
  • API mismatch : it is different from the servlet API and less hacks are possible, like the deadly usage of HTTPServletRequest#getRequestURI()
  • invocation mismatch : needs to use a PortletURL to perform invocation to itself and not create URLs directly
  • context mismatch : portlet have portlet mode, window state and preferences which influence the markup of the producer
  • markup : a portlet is capable to produce markup adapted to a specific device (cellphone for instance)


JSF is slightly different in the sense that it is agnostic of the execution context (servlet of portlet). JSF is designed to run from the beginning with portlets and servlets whereas other framework not (cf. Stan's presentation).


It seems that if you need to run your apps in those two contexts, today JSF is the framework to use :

  • it has a spec
  • it is integrated in JEE 5
  • it should have decent tools
  • it can adapt its markup because it has renderers, this is a great asset for JSF to have skinnable components and have the behaviour of the component decoupled from the markup used


But I think that there is a gap for a simple framework for portlets. As said we have JSF but it is complicated. I will change my mind if someone can explain me in 1 hours how JSF works (not how to write an hello world application).


Also JSF does not care about the execution context. For instance if the window state is MAXIMIZE, MINIMIZED or NORMAL it will render the same markup.


Then we have Struts Shale a web framework that is based on JSF. I don't know if it makes sense or not. If it exists, does this mean that JSF is not sufficient by itself ? Or people want to have a Struts like programming model (Model 2) rather than of component model ? So I don't know yet what to think of that effort.


For other frameworks, I don't know them much so I will not critisize but try to comment anyway :

  • Tapestry has a similar model to JSF, so it cannot compete, except with technological innovation. It seems that Tapestry has always been a techonology innovator, however it has always been complicated to use it. I know that Howard simplified Tapestry a lot since the 3.x series after an constructive discussion with another colleage of mine
  • Struts will finish his life peacefully as it is planned, yet it should be continued to be used imho because it has lot of momentum
  • Webwork : I don't know it
  • Wicket : I haven't looked at it yet

    To conclude, JSF has a satisfactory support for portlets so you can invest your resources here. However there is a place for a specific portlet framework that would leverage portlet features that are not used by othe frameworks like portlet modes and window states.

What architecture changes will you see in JBoss Portal 2.2 ?

Module overview


First let me give you a overview of the different functional modules we have in JBoss Portal 2.2 :


The base module is the server. The server goal is to provide the middleware infrastructure that is leveraged by other modules. By that we mean all the low level services of the server, like :

  • Deployment : this service is integrated with the JBoss microkernel deployment layer in order to intercept war files and create containers based on the deployment descriptor it can find in web archives. The other responsability task is to instrument web containers in order to introduce servlets that will provide the server a way to invoke portlets deployed in the war files. The current implementation of the deployment service is totally transparent and does not require any modification of the war files you deploy in the directory /deploy of JBoss application server.
  • Invocation : defines how we perform invocation at different levels and most importantly how the layers communicate and exchange information. This is going to be discussed later in this article.
  • Container : simply an abstract notion of container that is reused in the server for different purposes.


Then we have the portlet module which implements the portlet container API contracts defined by the JSR 168 specification and depends on the server, the theme module which defines our theme framework.


Finally the core reuse all the above modules and provide our business implementation of the portal based on additional services like user management and content management.

Changes since 2.0


After having introduced the different modules of the whole portal, we can concentrate now on the server. I will describe now in detail the pipeline used during the rendering of a portal page.


For the 2.2 release keep the same aspect based approach but we introduce a little bit more flexibility in the stack. The approach we chose for 2.0 is based on a unique stack, the main changes we added are :


    Separate the invocation stacks


    one global stack invoked at each request that apply request scoped aspect, for instance :

    • Retrieve user
    • Determine the content type
    • Determine the locale


    one local stack per portlet where aspects focus on the request to a single portlet, for instance :

    • navigational state
    • compute preferences
    • request dispatching


    Introduce a controller between the two stacks


    The controller goal is to let the server implement a specific behavior when a request is done to the portal. For instance, in order to test the portlet container we have a very simple controller that does nothing but aggregate portlet and invoke them. The controller has total freedom on what it does as it is placed between the server stack and the component stacks. In fact it is really up to the controller to decide what components are involved in a request, perform the interractions and aggregates the results in the response sent to the client.


    The core portal in JBoss Portal is built on top of this server + component framework and leverages a more complete controller that is based on pages to tie portlet together, therefore we provide a specific implementation of the controller.


    As you can see on the picture, the invocation stack reuse a generic invocation API that is well adapted for the portal environment The calling layer creates a detyped Invocation object which contains the Request and Response. When doing such it must implement a service provider interface (spi) in order to provide services to the layer it is calling, these are symbolised by the RequestContext and the ResponseContext interfaces.


    Once the calling layer has created an Invocation, it uses it to call the layer it is targetting and between the calling and the called layer we apply a set of Interceptor that create step by step the context into which the called layer will operate. For instance, deciding the content type for the life time of the request is done at this places.


    This approach gives the opportunity to have a very flexible approach for the implementation as it is possible to fully customize the invocation stacks.

We have seen how JBoss Portal is organized as functionnal modules and how the server module invocation pipeline works. This is still a work in progress and JBoss Portal 2.2 will see new features and modules like the WSRP specification which is being implemented as a separate module. If you are willing to help on this effort you are welcome to contribute by visiting our forums which is the main place to start and the JIRA tracker.