Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2011.01
-
servicemix-bean, servicemix-camel, servicemix-cxf-bc, servicemix-cxf-se, servicemix-drools, servicemix-eip, servicemix-exec, servicemix-file, servicemix-ftp, servicemix-http, servicemix-jms, servicemix-ldap, servicemix-mail, servicemix-osworkflow, servicemix-quartz, servicemix-saxon, servicemix-scripting, servicemix-smpp, servicemix-snmp, servicemix-truezip, servicemix-validation, servicemix-vfs, servicemix-wsn2005, servicemix-xmpp
-
None
Description
In a plain JBI scenario, every JBI component has the JBI shared library as its parent classloader. When we add the JBI components in ServiceMix 4, we're not using JBI packaging but we deploy them as OSGI bundles instead. Currently, these OSGi bundles only import the packages they need from the shared library bundles, but this sometimes causes problems when people move existing SAs from ServiceMix 3 to ServiceMix 4.
If we add the shared-library bundles as {{Required-Bundle}}s to the JBI components, the classes available in the component would be a lot more similar than what we have in ServiceMix 3. Required-Bundle is not usually recommended in OSGi as it is too course-grained, but in this case there shouldn't be a real problem as we don't support multiple versions of the same JBI component anyway and the goal is to simulate the JBI classloader behavior.