Tweeting from JBoss Portal

While most of time we focus on improving enterprise aspects of JBoss Portal (read JBoss Enterprise Portal), sometimes we work on cool and fun stuff too. On that line, I have created Twitter portlet which has following features:

• Update your status
• Get messages that are sent directly to you (e.g. @prabhatjha in my case)
• Get list of folks who you are following and get their latest status. List is sortable.

Here are couple of screen shots:


You can grab the code from http://anonsvn.jboss.org/repos/qa/prabhat/twitter-portlet . It's built using twitter4j, Richfaces, JBoss Portlet Bridge. But remember, it's just for fun and it is not one of the supported portlet.

Forums and Wiki projects

The original authors of JBoss Forums and JBoss Wiki (respectively led by Ryszard Kozmik and Tomek Szymanski) having retired from those projects (Ryszard being Content Management lead at JBoss.org and Tomek leaving Red Hat). The two projects have stalled for some time now.

Luckily we got not one not one and a half but two motivated contributors from Italy to come help maintain and enhance those projects.

Not everything is sorted out yet (the projects page are not updated and the Jira neither) but at least we have code and binaries to play with in JBoss Portal 2.6 or JBoss Portal 2.7.

Piergiorgio Lucidi (Maven addict) moved JBoss Wiki to a Maven 2 build system and added support for JBoss Portal 2.7. Sources are available here and compiled binaries on PortletSwap.

Luca Stancapiano (you may remember his contributions such as the admin portlet internationalization and Italian localization) worked on JBoss Portal 2.7 support for the Wiki portlet. Sources are available here and binaries also on PortletSwap.

So many thanks to Piergiorgio and Luca and I'm sure they would welcome more help on those projects :)

Portlet coordination

Portlet coordination is a new set of features brought by the Portlet 2.0 specification (aka JSR-286).
You can now define what is called "Public (or shared) render parameters" and events. The specification only defines the portlet *container* and not how portlets behave in a portal. It is up to the portal vendor to define how those shared render parameters and events will be bound.

In JBoss Portal we treat Shared render parameters in a similar way as events. We named "Event wiring" a link between an event to publish and an event to consume and "Parameter binding" the link between parameters. An event and a shared parameters are defined by a qualified name in a portal.

Implicit coordination
The most natural way it to bind (or wire) shared parameters (or events) that defined the same qname on the same page. This is the default behavior in JBoss Portal, and we call that "implicit binding" (or "implicit wiring" for events).

Here is a schema to understand, the portlets 1, 2, 3 define a render parameter called "urn:other:zip" while the portlet 4, 5, 6 define a render parameter called "urn:jboss:zipcode".
With the default behavior "implicit binding" any portlet modifying or accessing a render parameter with share the same value

Explicit coordination
This is a natural and common use case, but there are time when you don't want that behavior, let's say you don't want them to share the same value and somehow want to isolate all those windows. You can turn off the implicit binding by either modifying the *-object.xml descriptor or through the GUI.

<portal>
...
<coordination>
 <bindings>
     <implicit-mode>FALSE<implicit-mode>
 <bindings>
 <wirings>
     <implicit-mode>TRUE<implicit-mode>
 <wirings>
<coordination>
<portal>

Here we turned off the implicit binding and kept the implicit wiring.
Now all our windows have their public render parameters isolated.


Now we may want something in the middle, not all magically bound, neither all separated, even better, we bought the portlet represented in blue that has a shared render parameter which also represent a zipcode like ours. We do not want to make modification to that acquisition we simply want to tell the portal that we want to bind the zipcodes of windows 1 4 and 5. On top of that we want to bind 2 and 3. This can also be done wither through the descriptor file or though the admin portlet.
We now have the following scenario, without changing any code.

Voila ! We now have a way to "explicitely" define how shared render parameters are bound and it works in a similar way for event wiring.
Of course a nice addition to this would be the possibility to transform a render parameter or event payload on the fly (say the portlet you bought defines an render parameter string that represents an address, the format will probably be slightly different from the one you made yourself, we would need a class in between to do the transformation back and forth). We'll see how this feature get popular and how we can put that in the roadmap, but contributions are always welcome :)
Aliases
Last but not least we've also added the notion of aliases for render parameters. Say you have the two shared render parameters "urn:jboss:zipcode" and "urn:other:zip", you know they are similar (it's just a string that contains a zipcode), you can group them in an alias. That alias name can be used to pass a value as a request parameter of the portal.
You can define the alias in the object descriptor or through the admin portlet, in the XML it would look like:

<coordination>
<bindings>
   <alias-binding>
      <id>myzip</id>
      <qname>{urn:jboss}zipcode</qname>
      <qname>{urn:other}zip</qname>
   </alias-binding>
</bindings>
</coordination>

Now by passing a request parameter to the page, the windows will get an initial value equals to the parameter you passed. Say your page URL is http://www.jboss-portal.org/portal/myPage you can pass a render parameters to your portlets by querying: http://www.jboss-portal.org/portal/myPage?myzip=20878, it's also what we call a page parameter.

I hope that I was able to give a not too long overview of implicit/explicit coordination, more details are available in the reference guide.

How to monitor portal session data and replication?

Lately we have been working a lot on improving JBoss Portal's performance and scalability. In this blog, I want to talk about how you can inspect what's in your session and how much data is getting replicated when a request is made to your portal deployment.

You can not get hold of HttpSession object in your portlet. To get hold of HttpSession object, either you write your custom interceptor or a filter. What you have is access to PortletSession object through getPortletSession method of request object where request could be a RenderRequest or ActionRequest. Unfortunately, there is no session.getSize() method which would tell you how big exactly your portlet session is. You would have to enumerate through attributes in session in both PORTLET_SCOPE and APPLICATION_SCOPE, get their values then obtain their size as follow:

Enumeration portletAttribs = session.getAttributeNames();
Enumeration applicationAttribs = session.getAttributeNames(PortletSession.APPLICATION_SCOPE);
ByteArrayOutputStream bs = new ByteArrayOutputStream();
ObjectOutputStream os = new ObjectOutputStream(bs);

while(portletAttribs.hasMoreElements())
{
   Object obj = session.getAttribute(portletAttribs.nextElement());
   os.writeObject(obj);
}

Similarly you enumerate through attributes in applicationAttribs and add write them to ObjectOuputStream. Then you get the size using:

System.out.println("PortletSession Size is " + bs.size());

The value you get is a close approximation to how big your portlet session is. HttpSession size will be bigger because portal needs to store the navigational state of your portlet/s as well.

Now, let's talk about how much data is getting replicated across your portal cluster. We will find this using JGroups MBean and JConsole which is the Java Monitoring and Management Console graphical tool shipped in J2SE JDK 5.0 and up.

First we need to prep up JBoss so that mbeans are available to JConsole. You can find the details at
JBoss-JConsole wiki. In a nutshell, you need to modiify $JBOSS_HOME/bin/run.conf. Your JAVA_OPTS should look more or less like

JAVA_OPTS="-Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dcom.sun.management.jmxremote -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanSe
rverBuilderImpl -Djboss.platform.mbeanserver"

Start JBoss Portal + JBoss AS bundle. In a separate terminal launch jconsole. You should automatically pick up PID of JBoss instance as shown here. Click Connect.


Now under MBeans tag, select Tree->jboss.jgroups -> protocol->Tomcat-Cluster->UDP as shown below. Here you will see total number of bytes sent and received by a node in cluster.



These Bytes Sent and Received value are for data related to session replication. To see replication data related to the second level cache used by Hibernate in Portal, you need to select
Tree->jboss.jgroups -> protocol->portal.hibernate->UDP

With those tools, you can now make sure that your sessions are not getting too large for the costly session replication on a cluster. You can use and abuse.

Julien Viet's Blog

I just want to signal people reading the JBoss Portal developer's blog that I just opened my official blog. I will share with you topics like portal, portlet, java, lot of cool stuff and my rants.

JBoss Portal 2.7 Alpha released

We have just released the alpha version of the upcoming of JBoss Portal 2.7 release that brings the Portlet 2.0 features to our mainstream product JBoss Portal.

The JBoss Portlet Container technology is included in this release and provides an out of the box support for the JSR 286 features such as:

• Portlet eventing
  
• Public pararemers
• Resource serving
• Portlet filters

Our admin  tool has been upgraded as well to support JSR 286.

Enjoy the release, you can get the files from the download page as usual!

JSF in a portlet has never been this easy!

We just released JBoss Portlet Bridge Beta3 along with some good supporting documentation and example projects. See the documentation for full details.

The majority of the code written for this release is internal to the portlet bridge project (refactoring, 301 spec updates and enhancements, bug fixes...). The next release (Beta 4 - early Sept) will be huge for the portlet bridge for the following reasons:

• The EG is currently discussing a lot of significant clarifications and improvements. For example, working with the JSF 2.0 EG to allow certain needs and working on Portlet 2.0 areas of the spec.
  
• There is currently a lot of discussion about navigation between portlet modes. Once this is nailed down in the spec, we will implement it.
  
• The Portlet 1.0 version should be getting close to public review.

Other than the spec related reasons for release schedule, we must work in unison with the latest Seam and RichFaces relases, make sure that we squash any bugs concerning the 3 integration points, handle features/improvements/refactorings, and try to test and give feedback to the 301 EG. And, of course we can't forget about JBoss Portal 2.7+!

There are soo many cool things going on right now within the JBoss Portal project, I would like to tell you about all of them but then this post wouldn't be about JBPB anymore. Just stay tuned to this blog...

With that said, here are a few tips for JSF portlet developers that concern this release:

• Namespacing
  In situations where you need to use the id of an element in your JSF/xhtml markup, you would normally see something like 'form1:myBtn' in the rendered markup. But now with the bridge namespacing you will see something similar to:

  jbpns_2fdefault_2fNews_2fStories_2fStoryTemplateWindow12snpbj:_viewRoot:form1:myBtn

  To overcome this, you can use the following expression in your Facelets page to prepend the namespace to your javascript code:

  document.getElementById('#{facesContext.externalContext.response.namespace}the_rest_of_JSF_ID

  since this uses the portletResponse, once you try to view this page on the servlet application side, you will get an exception. To avoid this, you need to check for the type of response in your backing bean and assign a new "safe" namespace variable for the UI.
  
  
• Excluding Attributes from the Bridge Request Scope
  When your application uses request attributes on a per request basis and you do not want that particular attribute to be managed in the extended bridge request scope, you must use the following configuration in your faces-config.xml. Below you will see that any attribute namespaced as foo.bar or any attribute beginning with foo.baz(wildcard) will be excluded from the bridge request scope and only be used per that application's request.
  

  
  <application>
       <application-extension>
           <bridge:excluded-attributes>
               <bridge:excluded-attribute>foo.bar</bridge:excluded-attribute>
               <bridge:excluded-attribute>foo.baz.*</bridge:excluded-attribute>
           </bridge:excluded-attributes>
       </application-extension>
      </application>

  
  Or you can use the javax.portlet.faces.annotation.ExcludeFromManagedRequestScope annotation to accomplish the same thing.
  

For more information on this release or to find out more about the project, visit the project page.

JBoss Portlet Container 2.0 GA Release

The JBoss Portal team is very proud to announce the release of the JBoss Portlet Container 2.0 product.

The release is a fully compliant implementation of the Portlet 2 (JSR286) specification, which was released yesterday.

JBoss Portlet Container 2.0 comes with a lightweight portal based on JSP tags and comes bundled with a few demonstration portlets. The goal of that lightweight portal is to provide developers with an easy way to showcase and test their portlet applications. It should work well with other JSP taglibs and templating frameworks.

It provides advanced functionalities:

• Administration application which provides an overview of the deployed applications / portlets / filters and management of their life cycle. Failed portlets or filters can be restarted or stopped when needed.
• Event debugger which should prove very userful to understand complex event interactions.
• Event flood detection to prevent events from running wild.
• Management of life cycle dependencies between portlet filters and portlet container: if a portlet filter fails and is stopped then all the portlet containers dependent on that filter will also be stopped (otherwise it would obviously result in an incorrect application).
• Optimized event payload marshalling: when an event with an object payload is fired from application A to application B, the event will be unmarshalled/marshalled between the two applications classloaders (otherwise it would result in a class cast exception) unless the event class is shared at the server level, in which case the event can be safely transported across application borders.
  

The next major release of our mainstream portal product JBoss Portal 2.7 will bundle the JBoss Portlet Container.

You can download the release from our project download page.

JBoss Portal @ Rotterdam JBug

The Rotterdam JBug is happening June 20th, Thomas and myself will be there to talk about Portlet 2.0 and the upcoming JBoss Portal 2.7 release. We'll give also a quick overview of the future releases.

The Benelux JBoss User Group is organizing an event on Friday June 20th 2008. There will be plenty of presentations:

• JBoss Portal - Julien Viet and Thomas Heute - JBoss
• Hibernate Search - Emmanuel Bernard - JBoss
• Woman in IT - (special guest presentation) Clara Ko and Linda van der Pal - jduchess.org
• JBoss Drools - Kris Verlaenen - JBoss

Here is more information, it's free of course but you need to register.

Can the Servlet 3.0 improve the development of Portlets?

I recently looked at the Java 3.0 API slides for JavaOne in order to catch up with what the expert group will provide in the next release of the spec. As a portlet container architect it is important to provide feedback to the expert group.

One of the challenge of developping and maintaining a portlet container is the capability to detect deployment of portlets and create associated portlet containers. Portlet are plain java classes in a war file, the main problem is to have the portlet container to be aware of the war file deployment life cycle in order to create / destroy the associated containers.

Another challenge is to have the capability to request dispatch to a war file from another a serviced request. This can only be done if a special servlet is added to the portlet application war file. So when a portlet application is deployed, the resulting web application must contain the special portlet container servlet. It is pretty much similar to:

public void service(HttpServletRequest req, HttpServletResponse resp) throws IOException, ServletException
{
// We access the context of the portlet application foo
ServletContext fooCtx = getServletContext().getContext("/foo");

// We obtain access to a servlet that will execute the portlet container
// It is important to request dispatch in order to do important stuff such
// as using objects from the foo application such as the http session or
// to have the thread context classloader of the foo application
RequestDispatcher rd = fooCtx.getRequestDispatched("/bar");

// We do an include but it should not modify the response (of course it depends on the implementation of
// the container / portal ...)
rd.include(req, resp);
}

We are able to provide solutions with different strategies, thanks to a framework that abstracts the various operations required by the portlet container and we have a couple of implementations.

We have one strategy that contains tomcat specific code and is able to detect application life cycle and modify it in a fully transparent manner. This is great for the developer as it does not require *any* modification of the portlet application, but this comes at the price of having code depending on tomcat, which is fine because tomcat is open source and we can integrate with it.

We also have a generic strategy that requires the portlet application developer to modify its war file and update the web.xml file to add a special servlet that will do all the magic. This is fine for development but this is a bit problematic when you download a thirdparty portlet application and deploy it because this forces you to edit the war file and modify it before deployment. Here is an example of what needs to be added to the war file:

<web-app>
...
<servlet>
<servlet-name>BootstrapServlet</servlet-name>
<servlet-class>org.jboss.portal.web.impl.generic.GenericBootstrapServlet</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>
...
<servlet-mapping>
<servlet-name>BootstrapServlet</servlet-name>
<url-pattern>/jbossportlet</url-pattern>
</servlet-mapping>
...
</web-app>

The nirvana is the fully transparent deployment of a portlet appliction and we are not yet there with the Servlet 3.0 spec... But the good news is that we are not far!

First the expert groups recognizes the need of the capability to modify of servlet context by providing runtime operations that will allow the addition of new servlets and create mappings dynamically:

...
servletContext.addServlet("BootstrapServlet", "The bootstrap servlet", "org.jboss.portal.web.impl.generic.GenericBootstrapServlet", null, -1);
servletContext.addServletMapping("BoostrapServlet", new String[]{"/jbossportlet"});
...

That would allow to replace the bootstrap servlet with a servlet context listener, which improves a bit the generic solution but is not yet fully transparent.

The second new feature that improves the generic solution is the modularization of web.xml, a new form a pluggability that allow to define servlets outside of web.xml in XML fragments. It is designed for frameworks. That should allow the packaging of the bootstrap servlet context listener (since now the listener could inject the servlet) in an xml fragment outside of web.xml and would allow to minimize the amount of work to do. Such xml fragments are located in the META-INF directory of any jar file bundled with the web application.

So what would become our generic implementation ? It would come as a jar file that would contain only the web xml fragment (because any portlet container classes have to be shared between all web applications...) that would be bundled in the WEB-INF/lib of the portlet application.

So we have a better generic solution now but it is not yet perfect. The expert group recognize there is a need for the various frameworks out there (even if the portlet container stuff is a special kind of framework, because of its cross context nature). When the Portlet expert group will work on a new revision of the spec, it would be great to have a solution to this problem so the Portlet spec could leverage it to provide a portable universal solution.

Personally I have a couple of suggestions in mind, I will try to blog them in the near future and maybe we could work out something with the Servlet expert group.

JBoss Portlet Bridge Beta2 Released

Supports:

• JBoss Portal 2.6.4
• Seam 2.0.2.CR1
• RichFaces 3.2.0.GA (with exception of upload component)
• JSF 1.2

This release of the bridge has quite a few bug fixes and enhancements:

• Portlet EL Variable support
• New SeamIdentity Bridge Extension: instant SSO between your Seam application and your JBoss Portal server by a simple dependency in your pom
• RichFaces Maven Archetype
• Removal of PortalStateManager configuration
• More documentation
  

---

EL Variable Support

portletConfig: object of type javax.portlet.PortletConfig

sessionPortletScope: mutable Map containing PortletSession attribute/values at PORTLET_SCOPE.

sessionApplicationScope: mutable Map containing PortletSession attribute/values at APPLICATION_SCOPE.

portletPreferenceValue: immutable Map containing the set of portlet preferences where the key is the name of the preference and the value is the first portlet preference value from the (potential) set of values.

portletPreferenceValues: immutable Map containing the set portlet preferences where the key is the name of the preference and the values are the set of this portlet preference's values.

---

SeamIdentity Bridge ExtensionJust add the following dependency to your JBoss Seam (Maven) project for SSO between JBoss Portal and Seam applications.

<dependency>
<groupid>org.jboss.portletbridge.extension.seam</groupid>
<artifactid>PortalIdentity</artifactid>
<version>1.0.0.B2</version>
</dependency>

RichFaces Maven Archetype
This is the new Beta2 release of the RichFaces archetype - only a few settings are different from the previous snapshot release.

mvn archetype:create
-DarchetypeGroupId=org.jboss.portletbridge.archetypes
-DarchetypeArtifactId=richfaces-basic
-DarchetypeVersion=1.0.0.B2
-DgroupId=org.whatever.project
-DartifactId=myprojectname
-DremoteRepositories=http://repository.jboss.org/maven2/

---

Removal of PortalStateManager configuration
The following is no longer needed in the faces-config.xml

 <state-manager>
org.jboss.portletbridge.application.PortalStateManager
</state-manager> 

Visit the Portlet Bridge project page for more details.

JBoss Portlet Container 2.0 Candidate Release 2

We have just released the candidate release 2 of the JBoss Portlet Container project.

 Since the candidate release 1 we added an administration portlet that can manage the life cycle of the deployed applications and containers.

We have also added a very useful event debugger that can help developers to understand the event flow distributed among the different portlets during the interactions an event phase.

You can download the release from our project download page.

JBoss Portal 2.7 status

I want to give our community an overview of the JBoss Portal 2.7 development status.

The good news is that the JBoss Portal 2.7 branch reached what I call the Milestone 1 which consist in the integration of the JBoss Portlet Container 2.0 with the same level of functionality than the current 2.6 product. Thomas and Chris were the main drivers in that effort and did a very good job.

We are heading now toward the Milestone 2 with the following simple goals:

Integrate the controller module of the JBoss Portlet Container: it allows to perform complex event interactions between portlets. Actually this is the integration point that the JBoss Portlet Container provides to the portal in order to integrate its event routing and transforming logic. There is a very simple implementation in the JBoss Portlet Container simple portal that uses a matching event routing algorithm, simple yet sufficient for the simple portal, right?

Provide JSR 286 Portlet runtime meta data overview through the administration portlet. The administrator is able to know about the coordination capabilities offered by a portlet such as the event it produces and the event it consumes. 

I will talk briefly about the Milestone 3 and will probably give more update about it when Milestone 2 will be reached:

• Define the coordination feature support, the event routing models and the portlet parameter sharing model
• Support for new JSR 286 state in portal URLs, mostly about support of public navigational state changes in the URLs
• Resource serving support

That's it for now, the entire team is focusing on reaching Milestone 2 very soon!!!!

RichFaces Portlet Archetype

I just finished creating a Maven archetype for the RichFaces portlet using the JBoss Portlet Bridge. An archetype basically gives you a empty project shell with all of the proper config files and package names that are custom to your project. It comes packaged with a simple demo of the RichFaces ajax repeater code.

From the command line run:

mvn archetype:create -DarchetypeGroupId=org.jboss.portletbridge.archetypes -DarchetypeArtifactId=richfaces-basic
-DarchetypeVersion=1.0.0-SNAPSHOT -DgroupId=org.whatever.project -DartifactId=myprojectname
-DremoteRepositories=http://snapshots.jboss.org/maven2/

Navigate to the newly created project folder and run mvn install - now you are ready to deploy the war file located in the target directory.

The Rise of the Portlet Containers

So now that the Portlet 2.0 spec is approved, it is very interesting to watch the evolution of the OSS market since the Portlet 1.0 spec.

The most noticeable change is the projectization of the portlet container technology. (I will not use the word productization because some of the projects release a complete product and some just make a dump of the source code of the project).  4 years ago the only standalone portlet container was Pluto (the Reference Implementation) and today there is an avalanche of at least 4 portlet container projects (including our JBoss Portlet Container product).

So the question is why do we have so many open source portlet container projects ? because a portlet container is an important piece of a portal and every one wants to develop its own portlet container ?

I think it answers partially the question. If you look a bit more closer at the portlet container technology, then you will see that there is an obvious lack of standard for embedding a portlet container in a portal, i.e a portal needs to chose a portlet container and use its proprietary API to interact with the container. Indeed the portlet specification does not specify that contract because this is the scope of the WSRP spec. As of today if a portal wants to reuse a portlet container in a portable manner, that portal needs to talk WSRP and nobody wants to do that!

So the rationalization of the market could drive to the adoption of a portal spec. It would provide the minimum basis to create a "Portal" profile in Java EE (which is today an hot topic!). Without a portal spec, I don't see any chance to have the portlet container technology part of Java EE.

JBoss Portlet Container 2.0 Candidate Release 1

I just released the first candidate release of our portlet container product with a few additional features since the beta:

• documentation : a product would not be a product without a documentation. The documentation has improved since the beta and now we have a complete section on the portal taglib and much more.
• optimized event payload marshalling : when an event with an object payload is fired from application A to application B, the event will be unmarshalled/marshalled between the 2 applications classloaders (otherwise it would result in a class cast exception) unless the event class is shared at the server level (optimization).
• life cycle dependencies between portlet filter and portlet container : if a portlet filter fails and is stopped then all the portlet container dependent on that filter will also be stopped (otherwise it would result obviously in an incorrect application).
• administration application which provides an overview of the deployed applications / portlets / filters and management of their life cycle. So it is possible to restart a failed filter or portlet, or stop them when necessary.
• event flood detection : in order to prevent event flood situations

The next release candidate release will probably be done once the public final draft of the spec is available on the JCP site and it should be a certified release.

We should add an event debugger that would help portlet developers to get the reporting of the event phase for debugging purpose. What a great addition to the product!

We'll blog soon about the integration roadmap of the portlet container product in our next release of the mainstream branch: JBoss Portal 2.7!!!!

Portlet 2.0 specification is approved

The spec has been approved on Monday, congratulations to the Expert Group led by Stefan Hepper!!!

You can expect the public final draft to follow soon and we'll do a release of our new product JBoss Portlet Container very soon!!!

Portlet 2 talk at OpenExpo in Bern

Next week I'll talk at the OpenExpo conference in Bern about the Portlet 2.0 specification.

You can get free passes on the OpenExpo website and my slot is on Thursday 13 at 11:50 am.

See you there!

JBoss World slides available

The JBoss World web site now provides the slides of the talks that were given there. You can now get our slides about JBoss Portal and Portlet 2.0 presentations.

Enjoy!

JBoss Microcontainer usage in JBoss Portlet Container

I planned to rewrite the life cycle support in our JBoss Portlet Container product a couple of months ago, I have started that task for a couple of days. The main reason is the addition of portlet filters which introduce a life cycle of the different container objects a bit more complex than what it used to be in the past.

 The current code only manages the portlet application and portlet container with a trivial one to many relationships between application and container.

 The rewrite will introduce the portlet filter object having a one to many relationship with the application and also a one to many relationship with a subset of the containers according to what the application developer describes in the portlet descriptor file.

 So far we have not used directly any state machine framework to manage that. The main reason is that we use JBoss MC in the JBoss Portlet Container product and we use the good old JBoss Microkernel in JBoss AS 4.2.

 One could argue that I should write my own stuff to manage that. Indeed even if it is not very hard to do and that a set of good test cases would help to achieve something reliable it would miss one crucial feature which is the interaction with the environment. Indeed we need to be able to make a portlet container or a portlet application able to depend on some service for instance and have that dependency managed by the hosting environment.

 Another motivation for the rewrite is to expose outside of the container a set of managed object that represent the applications, the containers exposing only a subset of the concerns:

• Life cycle management wired to the MC and not directly to the container obviously
• Expose runtime meta data like portlet info

 In the implementation using JBoss MC, I have been able to simplify a couple of stuff thanks to an interesting feature called deployment callback. It allows to install/uninstall (a special kind of injection but with no managed dependency) all the beans (that's how JBoss MC names its POJO citizens) having a certain class. So this feature allowed me to remove a bunch of wiring code and simplify my stuff.

 The documentation is very good although it is missing some parts, but it's ok as I don't need those part (yet... Mark and Ales if you read me :-) ).

 The integration of our build with Maven improves also a lot about my understanding of JBoss MC, since Idea is able to download sources which helps to understand the kernel API stuff.

 Once I am done with that, I should work on getting the CC/PP portlet feature implemented and than I'll try to upgrade the JBoss MC version to the one matching JBoss AS 5 Beta 4. I'll try to keep you informed about that.