Things like this is why we need CDI support. Do we honestly think that our users will be able to develop portlets leveraging GateIn services if they have to understand all this? Not to mention the fact that they'd be tied to our implementation details and not on a standard… :/ For a little more context, Matt is working on packaging the WSRP-related artifacts into something a little more manageable than what is currently the case. From my (and probably our users') point of view, the switch to GateIn has resulted in a loss of usability on the WSRP side of things. Accessing the WSRP admin tool is a pain and we have artifacts all over the place (well, in gatein.ear and gatein.ear/lib). In JBoss Portal, we had the whole WSRP functionality packaged into a single SAR file that could be deployed/undeployed at runtime which resulted in the automatic addition of the WSRP admin tool to the administration pages when the service was deployed. To remove the WSRP services, it was as simple as remove the SAR file. One file, that was it. I have asked Matt to investigate ways to improve the current situation in GateIn because I feel we should provide at least equivalent (if not better) usability to our users than we did with JBoss Portal. On Aug 31, 2010, at 4:01 AM, Marko Strukelj wrote: > > 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&gt; 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 > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev