[
https://issues.apache.org/jira/browse/CAMEL-8638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Diesler updated CAMEL-8638:
----------------------------------
Description:
There are properties on CamelContext that should be immutable after context
start.
For example the application classloader associated with a CamelContext is not a
dynamic thing. You are supposed to
1. Create the CamelContext
2. Configure it (i.e. setApplicationContextClassLoader, etc)
3. Start the CamelContext
Reconfiguring the CamelContext at runtime would lead to undefined behaviour. If
a higher level supports dynamicity in that classloader, it should set the
application classloader to something that supports that.
Dynamicity in classloading is generally problematic because Java does not have
a notion of "unload class", which would apply to the remove and replace cases.
For example:
* CL loads type A1 - CL gets reconfigured so that A1 is no longer available -
loading of A1 is now inconsistent
* CL loads type A1 - CL gets reconfigured so that A1 is something else -
loading of A1 is again inconsistent
was:
There are properties on CamelContext that should be immutable after context
start.
For example the application classloader associated with a CamelContext is not a
dynamic thing. You are supposed to
1. Create the CamelContext
2. Configure it (i.e. setApplicationContextClassLoader, etc)
3. Start the CamelContext
Reconfiguring the CamelContext at runtime would lead to undefined behaviour. If
a higher level (i.e. your code) supports dynamicity in that classloader, it
should set the application classloader to something that supports that.
Dynamicity in classloading is generally problematic because Java does not have
a notion of "unload class", which would apply to the remove and replace cases.
For example:
* CL loads type A1 - CL gets reconfigured so that A1 is no longer available -
loading of A1 is now inconsistent
* CL loads type A1 - CL gets reconfigured so that A1 is something else -
loading of A1 is again inconsistent
> Enforce immutability of camel context properties
> -------------------------------------------------
>
> Key: CAMEL-8638
> URL: https://issues.apache.org/jira/browse/CAMEL-8638
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Thomas Diesler
> Fix For: 3.0.0
>
>
> There are properties on CamelContext that should be immutable after context
> start.
> For example the application classloader associated with a CamelContext is not
> a dynamic thing. You are supposed to
> 1. Create the CamelContext
> 2. Configure it (i.e. setApplicationContextClassLoader, etc)
> 3. Start the CamelContext
> Reconfiguring the CamelContext at runtime would lead to undefined behaviour.
> If a higher level supports dynamicity in that classloader, it should set the
> application classloader to something that supports that.
> Dynamicity in classloading is generally problematic because Java does not
> have a notion of "unload class", which would apply to the remove and replace
> cases.
> For example:
> * CL loads type A1 - CL gets reconfigured so that A1 is no longer available -
> loading of A1 is now inconsistent
> * CL loads type A1 - CL gets reconfigured so that A1 is something else -
> loading of A1 is again inconsistent
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
