Hi Freeman,
I think after reading all the discussion I understand that it is not a
better way to solve the problem so I will take my proposal back as
Willem tried to do the same exercise in past and had problems.
Regards,
Ulhas Bhole
Freeman Fang wrote:
Hi Ulhas,
Just FYI, there's a similar issue [1] before, and for me so far I have
no better way to solve this problem.
[1]https://issues.apache.org/activemq/browse/SMXCOMP-15
Regards
Freeman
On 2009-7-16, at 下午10:29, Ulhas Bhole wrote:
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
