On Sunday, October 28, 2012 at 1:03 AM, Raul Kripalani wrote:
> Looks like my reply wasn't delivered to the list on Oct 22nd... Here
> it goes again:
>
> Hi Willem,
>
> With regards to the integration test, the Processor that compares
> classloaders sits right after the consumer endpoint. So, if it
> succeeds when 2 or more bundles share the same HTTP port, we can be
> certain that the Jetty consumer has set the TCCL correctly. Otherwise,
> at least 1 of them would have the wrong TCCL.
>
> Regardless of what happens afterwards in the route, the Jetty consumer
> has done it's job correctly.
>
> In a more complex scenario, even if there was a threads() DSL or any
> other DSL that runs on a separate threadpool, it's understood that the
> threadpool would have been created by the Camel Context itself, so the
> TCCL will be correct anyway. Isn't this the case?
Yeah, you made a good point, we can update the TCCL for the thread pool which
is created by Camel.
>
> 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
--
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
