ProfileService shutdown and undeploy order

[adrian.brock]

The problem with the NoInitialContext in the all configuration
is because it is not undeploying the in the reverse order of deployment.

17:49:05,946 ERROR [DefaultPartition] partition unbind operation failed
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
 at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)
 at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
 at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:284)
 at javax.naming.InitialContext.unbind(InitialContext.java:375)
 at org.jboss.ha.framework.server.ClusterPartition.stopService(ClusterPartition.java:408)

The issue is that the ProfileServiceBootstrap just does a MainDeployer.shutdown()
but this just undeploys in "random" order.

 private Map<String, DeploymentContext> topLevelDeployments = new ConcurrentHashMap<String, DeploymentContext>();

 public void shutdown()
 {
 lockWrite();
 try
 {
 while (topLevelDeployments.isEmpty() == false)
 {
 // Remove all the contexts
 for (DeploymentContext context : topLevelDeployments.values())
 {
 topLevelDeployments.remove(context.getName());
 removeContext(context, true);
 }

 // Do it
 process();
 }

In the example above, conf/jboss-service.xml is undeployed before
the clustering deployment.

This can obviously be fixed, but I guess what should really be happening
is the ProfileService undeploys in reverse order of stages,
i.e. APPLICATION then DEPLOYER then BOOTSTRAP.

The MainDeployer.shutdown() should just be there to catch things
that don't undeploy themselves properly.

The problem is that the Profile api doesn't guarantee any ordering

 Collection<VFSDeployment> getDeployments(DeploymentPhase phase) throws Exception;

even though it is implemented as ordered in ProfileImpl using LinkedHashMaps

 private LinkedHashMap<String, VFSDeployment> bootstraps = new LinkedHashMap<String, VFSDeployment>();
 private LinkedHashMap<String, VFSDeployment> applications = new LinkedHashMap<String, VFSDeployment>();
 private LinkedHashMap<String, VFSDeployment> deployers = new LinkedHashMap<String, VFSDeployment>();

[starksm64]

This can obviously be fixed, but I guess what should really be happening
is the ProfileService undeploys in reverse order of stages,
i.e. APPLICATION then DEPLOYER then BOOTSTRAP.

The MainDeployer.shutdown() should just be there to catch things
that don't undeploy themselves properly.

The problem is that the Profile api doesn't guarantee any ordering

 Collection<VFSDeployment> getDeployments(DeploymentPhase phase) throws Exception;

Certainly the phases should be undeployed in reverse order. If needed the deployments api could express ordering using a List, but should that be necessary? If it started correctly it should stop correctly unless new dependencies are being accessed during shutdown.

[brian.stansberry]

The HAPartition bean is just doing this in stopService():

ctx = new InitialContext();
ctx.unbind(boundName);

In startService() it's more complicated, but essentially creates a new default InitialContext and does a rebind. So, no accessing a different dependency in stopService().

The bean has a depends on jboss:service=NamingService.

Looking at the javax.naming code, it looks like the only way the reported error would happen would be if the conf/jndi.properties file were no longer on the classpath. Would the incorrect ordering problem Adrian's mentioned result in conf/ being taken off the classpath prematurely?

BTW, IIRC the failure message has changed; used to mention org.jboss.iiop.naming.ORBInitialContextFactory, perhaps as a CNFE. Wouldn't surprise me if solving the current error condition just brings that one back.

[adrian.brock]

Actually there were two issues.

1) The issue described above where deployments were undeployed in random
order so the conf/jboss-service.xml classloader which includes the IIOP naming
context class was removed too early.

2) The undeploy was using the NoAnnotationURLClassLoader of bootstrap-beans.xml
as the context classloader which wouldn't be able to see that classloader anyway.

I've fixed (1)
http://jira.jboss.com/jira/browse/JBAS-5175

I've hacked around (2), but the proper fix will have to wait for the update
to the MC that does the proper context classloader setting
http://jira.jboss.com/jira/browse/JBAS-5176

[adrian.brock]

BTW, IIRC the failure message has changed; used to mention org.jboss.iiop.naming.ORBInitialContextFactory, perhaps as a CNFE. Wouldn't surprise me if solving the current error condition just brings that one back.

Yes, the way it was working, it couldn't see conf/jndi.properties either.

When the latest MC code gets into trunk,
your stop() will be invoked with the context classloader of your deploy/cluster
deployment so all this hacking around with the context classloader in the profile service
will go away.

[slaboure]

The HAPartition bean is just doing this in stopService():

ctx = new InitialContext();
ctx.unbind(boundName);

In startService() it's more complicated, but essentially creates a new default InitialContext and does a rebind. So, no accessing a different dependency in stopService().

The bean has a depends on jboss:service=NamingService.

(
BTW, maybe we should have a notion of implicit services applied to multiple inner-services i.e. a wrapping tag applied to multiple inner-service definitions so that it would be possible to assign global "services" (or default services) en masse. Things like the naming service for example, while a singleton today, might not be a a singleton anymore tomorrow (if we want to make JBoss AS 5.x a "multi-tenant" implementation i.e. SaaS hosting infrastructure for example).
)