[
https://issues.jboss.org/browse/JBESB-3582?page=com.atlassian.jira.plugin...
]
Tom Cunningham commented on JBESB-3582:
---------------------------------------
Did a little work trying to narrow down when the behavior changed for ESB :
jbossesb-4.7 + 5.1.0.GA : test case works (see Version 2.0)
jbossesb-4.8 + 5.1.0.GA : test case works (see Version 2.0)
jbossesb-4.9 + 5.1.0.GA : test case breaks (see Version 1.0)
JBESB_4_9_CP1_ER8_2 + 5.1.0.GA : test case breaks (see Version 1.0)
So the behavior changed somewhere between jbossesb-4.8 and jbossesb-4.9.
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