camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Diesler (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-8638) Enforce immutability of camel context properties
Date Wed, 15 Apr 2015 07:31:59 GMT

     [ 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)

Mime
View raw message