I added a redeployment of the web container as part of the new SingleSignOnUnitTestCase and this is breaking tests that rely on wars nested inside other deployments like the RMI/HTTP tests which use the http-invoker.sar/invoker.war.
The problem is that the redeployment of the container triggers redeployment of the nested wars and this removes the war class loader from the loader repository, but in the case of a nested war, a new class loader is not created because it inherits its containing deployments class loader. Possible workarounds would be: - Redeploy the entire deployment containing the war. This is a heavyweight solution. - Support reconfiguration the web container with a redeploy notion for the current wars that would use the current war deployment class loader. This is a different redeployment semantic than suggested by the optional redeploy operation in the j2ee deployment api. However, this api does not support the redeployment of a child component so this scenario is beyond the scope of the api. The intersection of deployment and mbean service life cycle is really too disconnected currently. This shows up in the current questionable behavior of the ServiceController in that it watches for class loader removal notifications and stops/destroys/removes services when their class loader is removed and waits to recreate/start these services when a new class loader shows up. This makes no sense as its mixing deployment and service life cycle notions in a poor manner. We need to define a complete state diagram that encompasses deployment, service life cycle, dependencies, and reconfiguration. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
