Just one comment from the TCCL setting on the CamelContinuationServletl， the unit test that you added doesn't have the thread switch even we used the async invocation API. So we need to set the TCCL somewhere incase the we need to use the camel application class loader in the other thread.
-- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: willemjiang On Monday, October 22, 2012 at 11:04 AM, Willem jiang wrote: > Hi Raul, > > The patches are looking good. > +1 for back porting them into 2.10.x and 2.9.x. > > -- > Willem Jiang > > Red Hat, Inc. > FuseSource is now part of Red Hat > Web: http://www.fusesource.com | http://www.redhat.com > Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) > (English) > http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese) > Twitter: willemjiang > Weibo: willemjiang > > > > > > On Monday, October 22, 2012 at 6:30 AM, Raul Kripalani wrote: > > > 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 > > (mailto: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> > > >
