[esb-issues] [JBoss JIRA] Updated: (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 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.
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
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