Hi JB,
I had the problem while working with Servicemix 3.3 equivalent (FUSE ESB
3.4) but the problem is apparent in both Servicemix 3.2 and Servicemix
3.3. I am not sure how it will work in Servicemix 4 with Pure OSGi
deployment? Possibly we might need to add similar option from OSGi side
where some dummy bundle would require but I am hoping Guillaume/Gert or
others who know OSGi stuff well would spot this mail and answer the
question.
I think for place is not important it can go into servicemix-utils or
servicemix-shared I don't mind where we put.
My question was more about will have any impact on OSGi based
deployments? Does anyone have any objection to the proposal or know any
existing or better way to do this.
Regards,
Ulhas Bhole
Jean-Baptiste Onofré wrote:
Hi Ulhas,
Thanks for your explanation.
I guess that you have add the problem using SMX 4, right ?
As servicemix-utils are already embedded into SMX and as this
servicemix-utils already contains util classes used by
servicemix-file, servicemix-soap, etc, we can put camel dependencies
into this utils.
What do you think of that ?
Regards
JB
Ulhas Bhole wrote:
Hi All,
I was recently caught by the ClassCastException even though the class
being casted was of same type while using servcemix-camel component
on redeployment scenario.
The problem was due to the class I was casting was loaded by Service
Unit's class loader and redeploy or deploying another SA using same
camel component (camel-cxf in this case) was not happy about it and
throw ClassCastException.
I was able to get around this problem by rebuilding servicemix-camel
component but also was able to get it to work with creating new
shared-library that contains additional components and
servicemix-camel have dependency on this shared library. This would
be much cleaner in terms of keeping the core servicemix-camel
component unaffected from the additional camel components that user
want to use.
Here is my proposal for the change: We can introduce new dummy
servicemix-camel-shared library which may (or may not) contain some
dependency or work like a place holder and servicemix-camel component
add dependency on this new shared library.
In default case it can be just empty shared-library which later a use
rebuild and add his own requirement (camel components) to it and this
will be much cleaner than asking people to rebuild (and possibly
pollute) servicemix-camel component.
I am interested in knowing people's reaction and possible problems
that I may have overlooked. I am especially interested in comments on
how it will affect servicemix 4 OSGi stuff.
Regards,
Ulhas Bhole
