Now also correcting the TCCL on Jetty consumers with disabled continuations: http://svn.apache.org/viewvc?view=revision&revision=1400734.
Regards, *Raúl Kripalani* Apache Camel Committer Enterprise Architect, Program Manager, Open Source Integration specialist http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk> On Sun, Oct 21, 2012 at 10:55 PM, Raul Kripalani <r...@evosent.com> wrote: > Hello, > > I've come across what I consider a critical bug in camel-jetty, given the > installed base of that component. > > When multiple Camel Contexts expose camel-jetty consumers on the same TCP > port, they share the underlying Jetty Connector. As a side effect of this, the > route runs with the classloader of the bundle/WAR that happened to create > the Connector first, i.e. the Camel Context whose Jetty consumer started > first. > > The issue shows up in OSGi environments or Application Servers or > containers that provide per-application or per-deployable classloaders. > Classloader isolation is effectively broken, so if bundle A and bundle B > both have Jetty consumers on port 9010 and bundle A starts first, the > requests routed to B will have the class loader from bundle A as the TCCL. > Thus, class resolution performed by B may fail if the OSGi imports are not > equal. > > The issue is logged under https://issues.apache.org/jira/browse/CAMEL-5722. > I committed a fix to trunk along with an OSGi Integration test on the > following revision: > http://svn.apache.org/viewvc?view=revision&revision=1400729. > > Would someone mind taking a quick look at this fix? If all seems correct, > I'll backport onto 2.9.x and 2.10.x. > > Thanks! > > *Raúl Kripalani* > Apache Camel Committer > Enterprise Architect, Program Manager, Open Source Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk> > >
