I think you're looking for this: http://wiki.exoplatform.com/xwiki/bin/view/Kernel/

Although it doesn't give you a very good feel for what's really going on when jboss is starting up and how kernel services get started.

I'll try to outline what I've learned and refreshed while writing this  ...

RootContainer initialization is supposed to occur within PortalContainerConfigOwner, or GenericHttpListener, or PortalContainerCreator, as part of portal.war, gatein-sample-ext.war or start.war). Let's call this a regular kernel startup.

Calling PortalContainer.getInstance() before the regular kernel startup will automatically trigger RootContainer initialization at the point and within context it wasn't necessarily intended - the only side-effect of premature RootContainer initialization I know for now is that MC integration may then not work if one day we need to use it.

During its initialization, RootContainer reads configuration of its services. It does this using ConfigurationManagerImpl to scan all default/deploy/*.ear archives' .jar libraries (lib/*.jar + declared java modules), default/lib/*.jar files, and default/conf/gatein directory, and finds all the conf/configuration.xml files.

By the time RootContainer has been fully initialized and started no PortalContainer has yet been initialized.

When portal.war or gatein-sample-ext.war are deployed they trigger creation of RootContainer, and register callbacks (called InitTasks) with it, but no initialization of any PortalContainer yet occurs. These callbacks will be trigger later.

There is a web application called starter.war, set up in such a way that it starts after all other gatein web modules. It is this one that finally triggers the creation of PortalContainers - which processes the previously registered InitTasks.

Only now does a PortalContainer get created for each portal, during which portal configuration is scanned (all default/deploy/*.ear archives for conf/portal/configuration.xml files + conf/configuration.xml within .war arhive of each portal web app - for portal specific services).

The whole roundabout mechanism is in place in order to support UnifiedClassLoading that allows for extensions to be deployed just by dropping them in and overriding any existing resources with new ones.

I think the simplest way to get access to current portal's services would then be to create a .jar containing conf/portal/configuration.xml where you register a service that implements Starter interface. You can drop this jar in gatein.ear/lib. The service will be instantiated and started once for each portal but long after your web application has already started. >From this service you would then need to push whatever information you need into your webapp.

Your webapp then needs to have lazy init, and wait with its final initialization until it gets pushed the info it needs ...

On Mon, Aug 30, 2010 at 8:59 PM, Matt Wringe <mwringe@redhat.com> wrote:

Where exactly should we be looking for the documentation for exo kernel?
I know there is some in the reference guide, but there is also
documentation on the exoplatform wiki.

All I want to be able to do is to access a service in the portal during
the deployment of an application. But configuration.xml files only
appear to be used when the server is first started, and if I access the
kernel directly in java (ie PortalContainer.getInstance) there doesn't
appear to be any way to guarantee that the dependent service is running
yet.

_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev