You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Raul Kripalani (JIRA)" <ji...@apache.org> on 2012/10/27 20:05:12 UTC
[jira] [Created] (CAMEL-5748) Classloader mixup in Direct VM
component
Raul Kripalani created CAMEL-5748:
-------------------------------------
Summary: Classloader mixup in Direct VM component
Key: CAMEL-5748
URL: https://issues.apache.org/jira/browse/CAMEL-5748
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.10.2
Reporter: Raul Kripalani
Assignee: Raul Kripalani
Fix For: 2.10.3, 2.11.0
The Direct VM component allows routes in different Camel Contexts to communicate with each other with all the benefits of the Direct endpoint (namely thread-sharing, thus enabling transaction to propagate across Camel Contexts).
However, the TCCL of the consumer route still remains the TCCL of the producer route. See CAMEL-5722 for a similar case.
I suggest fixing this by introducing a proxy processor at the consumer that sets the appropriate classloader, and sets it back when done. Note: remember to take into account exception scenarios, i.e. we should catch exceptions from the forward call to .process(), reset the classloader and rethrow the exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5748) Classloader mixup in Direct VM
component
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-5748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-5748:
-------------------------------
Component/s: osgi
Fix Version/s: (was: 2.10.3)
2.10.4
> Classloader mixup in Direct VM component
> ----------------------------------------
>
> Key: CAMEL-5748
> URL: https://issues.apache.org/jira/browse/CAMEL-5748
> Project: Camel
> Issue Type: Bug
> Components: camel-core, osgi
> Affects Versions: 2.10.2
> Reporter: Raul Kripalani
> Assignee: Raul Kripalani
> Fix For: 2.10.4, 2.11.0
>
>
> The Direct VM component allows routes in different Camel Contexts to communicate with each other with all the benefits of the Direct endpoint (namely thread-sharing, thus enabling transaction to propagate across Camel Contexts).
> However, the TCCL of the consumer route still remains the TCCL of the producer route. See CAMEL-5722 for a similar case.
> I suggest fixing this by introducing a proxy processor at the consumer that sets the appropriate classloader, and sets it back when done. Note: remember to take into account exception scenarios, i.e. we should catch exceptions from the forward call to .process(), reset the classloader and rethrow the exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5748) Classloader mixup in Direct VM
component
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-5748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485923#comment-13485923 ]
Claus Ibsen commented on CAMEL-5748:
------------------------------------
I wonder if there is anywhere in OSGi spec that says that the TCCL must be the classloader from the current bundle?
When you use OSGi service registry and invoke services across bundles, what is the TCCL then?
> Classloader mixup in Direct VM component
> ----------------------------------------
>
> Key: CAMEL-5748
> URL: https://issues.apache.org/jira/browse/CAMEL-5748
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.10.2
> Reporter: Raul Kripalani
> Assignee: Raul Kripalani
> Fix For: 2.10.3, 2.11.0
>
>
> The Direct VM component allows routes in different Camel Contexts to communicate with each other with all the benefits of the Direct endpoint (namely thread-sharing, thus enabling transaction to propagate across Camel Contexts).
> However, the TCCL of the consumer route still remains the TCCL of the producer route. See CAMEL-5722 for a similar case.
> I suggest fixing this by introducing a proxy processor at the consumer that sets the appropriate classloader, and sets it back when done. Note: remember to take into account exception scenarios, i.e. we should catch exceptions from the forward call to .process(), reset the classloader and rethrow the exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5748) Classloader mixup in Direct VM
component
Posted by "Raul Kripalani (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-5748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485965#comment-13485965 ]
Raul Kripalani commented on CAMEL-5748:
---------------------------------------
That's a good point. Just searching on Google for "thread context classloader osgi" shows that Camel is not the only project in pain due to possible under-specification from OSGi... http://apache-felix.18485.n6.nabble.com/Can-the-thread-context-classloader-issue-be-solved-at-all-td4835872.html#a30704352
> Classloader mixup in Direct VM component
> ----------------------------------------
>
> Key: CAMEL-5748
> URL: https://issues.apache.org/jira/browse/CAMEL-5748
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.10.2
> Reporter: Raul Kripalani
> Assignee: Raul Kripalani
> Fix For: 2.10.3, 2.11.0
>
>
> The Direct VM component allows routes in different Camel Contexts to communicate with each other with all the benefits of the Direct endpoint (namely thread-sharing, thus enabling transaction to propagate across Camel Contexts).
> However, the TCCL of the consumer route still remains the TCCL of the producer route. See CAMEL-5722 for a similar case.
> I suggest fixing this by introducing a proxy processor at the consumer that sets the appropriate classloader, and sets it back when done. Note: remember to take into account exception scenarios, i.e. we should catch exceptions from the forward call to .process(), reset the classloader and rethrow the exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5748) Classloader mixup in Direct VM
component
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-5748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485928#comment-13485928 ]
Claus Ibsen commented on CAMEL-5748:
------------------------------------
I assume camel-quartz may have this issue as well as the quartz scheduler is shared in osgi land.
> Classloader mixup in Direct VM component
> ----------------------------------------
>
> Key: CAMEL-5748
> URL: https://issues.apache.org/jira/browse/CAMEL-5748
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.10.2
> Reporter: Raul Kripalani
> Assignee: Raul Kripalani
> Fix For: 2.10.3, 2.11.0
>
>
> The Direct VM component allows routes in different Camel Contexts to communicate with each other with all the benefits of the Direct endpoint (namely thread-sharing, thus enabling transaction to propagate across Camel Contexts).
> However, the TCCL of the consumer route still remains the TCCL of the producer route. See CAMEL-5722 for a similar case.
> I suggest fixing this by introducing a proxy processor at the consumer that sets the appropriate classloader, and sets it back when done. Note: remember to take into account exception scenarios, i.e. we should catch exceptions from the forward call to .process(), reset the classloader and rethrow the exception.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira