[esb-issues] [JBoss JIRA] Commented: (JBESB-3582) SOA-P 5.1.0 classloader caching issues with embedded jar artifacts
[
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
SOA-P 5.1.0 classloader caching issues with embedded jar artifacts
------------------------------------------------------------------
Key: JBESB-3582
URL: https://issues.jboss.org/browse/JBESB-3582
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Deployment
Affects Versions: 5.0 Milestone Release 1
Environment: Windows 7, Fedora 14
Reporter: Dave Siracusa
Attachments: helloworld.daves.zip
An existing .ESB file with embedded jar artifact ends up being used for subsequently
deployed .ESB applications even if the second ESB contains a newer/different version of
the embedded jar artifact.
If you repeatly redeploy the first and the second, eventually the ESB file fails to
deploy due to duplicate class issues.
SOA-P 5.0.0/1/2 does not behave this way as the VFSClassloader uniquely captures each
artifact in the tmp vsf folder.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira