9:01 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev