On Tue, Aug 31, 2010 at 3:34 PM, Matt Wringe <mwringe@redhat.com> wrote:

This is what I have been trying:

- Using configuration.xml file added to a jar. Java class implementing
startable and using the constructor to manage the dependencies. This
works but only if the archive is deployed when the server is started.
This doesn't work if the jar/war gets deployed after the server is
started, or if the archive is removed while the server is still running.
- Adding a configuration.xml file to the WEB-INF/conf directory doesn't
seem to do anything unless its setup to be a portal extension.

- Using a servlet or servletcontextlistener. If I use a java class to
access the PortalContainer (eg
PortalContainer.getInstance().getComponentInstance). This will work if
the app is deployed after the portal is fully started, but it will not
work if the app is deployed when the server is starting. During startup
the servlet/servletcontextlistener will be started before the kernel
services are loaded, which results in null objects. Server shutdown has
the same problem.

I am missing some step here to get this to work properly? Do I need to
hook into some init process for the kernel?

The TaskInit mechanism I described - as used by PortalContainerConfigOwner, GenericHttpListener, and PortalContainerCreator can probably be used to factor your webapp in a way that it gets 'events' when the portal is instantiated. You create your own listeners, and register them with RootContainer for specific events. It's a more complex mechanism compared to the simple one I described previously, but possibly a more 'proper' one, as there are already webapps using it (i.e. portal.war).

But that's not an undeploy/redeploy solution as Julien pointed out - just an additional lifecycle / factoring mechanism to organize your webapp using listeners to receive events at the right time, and initialize itself at that point.

Your webapp will still have to:

1) be deployed at jboss start time

2) startup without relying on PortalContainer services, and exist in 'uninitialized mode' for a while and serve HTTP status 500 responses for a while, fully initialize its state upon InitTask event execution / callback at which point it will flip into proper operation.

3) won't be redeployable