Hi Guillaume,
Cool , I will head to write a camel-example to show how to create this
kind of SU which is using this camel extension SL :)
Cheers,
Willem
Guillaume Nodet wrote:
I'm actually working on the OSGi bits and should commit something very
soon, so we would not need such a shared library in smx4.
For smx3, is the point #2 really needed ? I would have thought
referencing the SL from the SU would work without problems and without
the need to hack the component's jbi.xml.
On Mon, Jul 28, 2008 at 10:51 AM, James Strachan
<[EMAIL PROTECTED]> wrote:
2008/7/28 Willem Jiang <[EMAIL PROTECTED]>:
Hi,
The camel component just contains the core camel jars, but some use cases
require the use of addon components (for example camel-cxf) which are not
present in the core camel jars. If you have multiple SU's with a dependency
on an addon component then you will hit classloading conflicts
(ClassCastException typically ). You currently need to:
1) Add the camel extension components to a jbi shared library
2) Edit the servicemix-camel service engine jbi.xml and add your shared
library.
Having to edit the servicemix-camel jbi.xml is not ideal so this enhancement
is to add a placeholder shared library to the camel-core component. The
shared library can be empty but will need to exist in the hot deploy
directory.
This would eliminate the need to hack the camel component's jbi.xml, you
would just need to edite the camel shared library pom.xml and override the
old camel shared library in the deploy directory.
Yeah, sounds good to me. The other option would just be to use OSGi
class loading rather than JBI 1.0 class loadering in ServiceMix 4 and
then its no longer an issue
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
