The easiest way to avoid this problem is to ensure you have unique package names. OSGi allows you to have an implementation of the a class in your bundle as well as import it (useful for providing default implementations).
As far as net.j11i.MyClass being in the dozer-osgi bundle - which version of Dozer are you using? I looked in v5.5.1 of the dozer-osgi bundle, and it isn’t there. Did you build dozer yourself and add this class? > On Apr 5, 2017, at 7:35 AM, JD Innocenti <jd.innoce...@gmail.com> wrote: > > Hi, > > Thanks for the reply! As I said to Quinn Stevenson, I recently had a > breakthrough on this issue. It turns out that it is due to a conflict during > class loading. In my aggregator, I have the following code: > > > > And this code results in newBody being null. However, if I replace this > with: > > > > This results in "java.lang.ClassCastException: net.j11e.MyClass cannot be > cast to net.j11e.MyClass". > > Apparently, it is possible for multiple class loaders to load the same class > (here, MyClass). Indeed, the command "osgi:find-class MyClass" finds two > hits: one in my bundle, and another in dozer-osgi. This makes sense, > considering I use a dozer transformation to create instances of MyClass. > > By renaming MyClass (to MyOtherClass) and rebooting (!), I manage to get my > application to work. However, by uninstalling and reinstalling my bundle, > the issue comes back. It looks like the class stays in some bundle's "cache" > when I uninstall/install my bundle... Whereas running the application > manually (or from the IDE) just loads everything "from scratch" everytime, > explaining why it works. > > The question I have now is: how can I prevent this conflict from happening? > My application is pretty simple, I don't play with classloaders manually... > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/AggregationStrategy-null-body-in-new-exchange-tp5796879p5797017.html > Sent from the Camel - Users mailing list archive at Nabble.com.
