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
