[ https://issues.jboss.org/browse/JBESB-3582?page=com.atlassian.jira.plugin... ] Dave Siracusa updated JBESB-3582: --------------------------------- Attachment: helloworld.daves.zip Pre-built ESB can be found in version-1 and version-2 directory. If you wish to build, please change the version property in the build.xml file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBESB-3582?page=com.atlassian.jira.plugin... ] Dave Siracusa updated JBESB-3582: --------------------------------- Steps to Reproduce: Wrong Class 1) deploy Quickstart_helloworld-1.esb 2) deploy Quickstart_helloworld-2.esb 3) Inpect server.log for telltail version Quickstart_helloworld-1.esb should display (server.log) Version 1.0, while Quickstart_helloworld-2.esb should display Version 2.0. Duplicate Class Deployment Error 1) re-deploy Quickstart_helloworld-2.esb several times 1) redeploy Quickstart_helloworld-1.esb was: 1) deploy Quickstart_helloworld-1.esb 2) deploy Quickstart_helloworld-2.esb 3) Inpect server.log for telltail version Quickstart_helloworld-1.esb should display (server.log) Version 1.0, while Quickstart_helloworld-2.esb should display Version 2.0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBESB-3582?page=com.atlassian.jira.plugin... ] Ales Justin commented on JBESB-3582: ------------------------------------ There is really nothing we can do to "fix" this. We could hack around this, so it might actually "work", but this would just be hiding the real problem == class-leak. The jdk caches the class against the originating classloader. http://download.oracle.com/javase/1.5.0/docs/api/java/lang/ClassLoader.ht... So if you try to load the class from cl#2 and it actually loads it from cl#1, the jdk will remember that for next time you invoke findLoadedClass() from #2 The classloaders have become linked. Thats why you need to redeploy both to properly refresh the classloading space and avoid classloader leaks. In our case cl#1 is the undeployed classloader, which we then still hit, due to leaking ref. But since we know it's undeployed, we ignore its result: Class<?> result = findLoadedClass(name); if (result != null) { // Has this classloader been undeployed? ClassLoader otherClassLoader = getClassLoader(result); if (otherClassLoader != null && otherClassLoader != this && otherClassLoader instanceof RealClassLoader) { RealClassLoader rcl = (RealClassLoader) otherClassLoader; // Ignore when undeployed if (rcl.isValid() == false) { if (trace) log.trace(this + " ignoring already loaded class from undeployed classloader " + ClassLoaderUtils.classToString(result)); result = null; // <--------------------------- HERE Hence we re-try to define it on cl#2. What I could do, is throw a better exception msg or at least add a warning instead of trace. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBESB-3582?page=com.atlassian.jira.plugin... ] Dave Siracusa commented on JBESB-3582: -------------------------------------- When I look in the vfs-nested.tmp folder (SOA-P 5.0.2 - below). I see unique instances of our common jars, one for each deployed ESB application. Providing us with virtual file system isolation we've grown to appreciate. Is there a legacy setting that would allow us to maintain VFS isolation, albeit with leaks? If not all our legacy apps need to be patched/retested in order to behave which is a big thing. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [jboss@ybkopesb01 vfs-nested.tmp]$ ls -R | grep ybesbcommon 68af5d56_ybesbcommon-2.0.0-SNAPSHOT.jar afcd539c_ybesbcommon-2.0.0-SNAPSHOT.jar f0d77c90_ybesbcommon-2.0.0-SNAPSHOT.jar f3d68c35_ybesbcommon-2.0.0-SNAPSHOT.jar -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBESB-3582?page=com.atlassian.jira.plugin... ] Dave Siracusa commented on JBESB-3582: -------------------------------------- I understand classloading in JBoss AS has a roller coaster history, unified, to hierarchal, vfs. So as of 5.1, classloading is no longer default hierarchal w/re/ to embedded jars? Many have grown used to embedding jars within war, ear, and esb artifacts. I see nothing in your release notes. Perhaps I missed it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBESB-3582?page=com.atlassian.jira.plugin... ] Travis Rogers commented on JBESB-3582: -------------------------------------- SOA-P 5.0.2 shipped with the EsbWebServiceDeployer which handles the deployment of the HTTP listener servlet by attaching JBoss Web metadata to the deployment. In SOA-P 5.1, this functionality has been rolled into the main EsbDeployer, which eliminated the exceptional behavior experienced with HTTP listeners in 5.0.2. This link [1] offers further explanation why scoping your deployments may be necessary for your desired set up. The explanation for this is that by default all war deployments are treated as isolated deployments. The change mentioned in [1] modified this behavior and made the war deployments as non-isolated. The interesting part is that when there is a HTTP listener in the esb, the entire esb deployment is treated as a war and hence got isolated. Thanks to EsbWebServiceDeployer, the VFSDeploymentUnit is attached with JBossWebMetaData and hence the JBoss Deployer thinks it is a war. [1] http://community.jboss.org/wiki/useJBossWebClassLoaderinJBoss5 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBESB-3582?page=com.atlassian.jira.plugin... ] Dave Siracusa commented on JBESB-3582: -------------------------------------- SOA-P 5.1.0 also deploys its own artifacts (WAR, RAR, ESB) as well as quickstarts. SOA-P also uses different dependent versions of common JARS. It is not known at this time whether ESB itself or other quickstarts are prone to classloading issues. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira