[ 
https://issues.apache.org/jira/browse/CAMEL-8000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Diesler resolved CAMEL-8000.
-----------------------------------
       Resolution: Won't Fix
    Fix Version/s:     (was: 2.15.0)

Closing as won't fix and removing what has been done already. 

If there is no defined create/destroy lifecycle for the CamelContext the system 
cannot reliably maintain the set of contexts.

As mentioned before, it is incorrect to call into 3rd party code with a 
partially constructed object. There is also no defined integration point to 
remove a context from a potential registry.

If a higher level API needs a context registry it should maintain it itself. 
The camel core layer should only need to provide an integration hook but no 
registry itself.

The existing Container API (among other flaws) also has a memory leak. Contexts 
that are created but never stopped will not get removed from the internal set 
when no Container is registered.

> Add global notion of CamelContextRegistry
> -----------------------------------------
>
>                 Key: CAMEL-8000
>                 URL: https://issues.apache.org/jira/browse/CAMEL-8000
>             Project: Camel
>          Issue Type: Improvement
>    Affects Versions: 2.14.0
>            Reporter: Thomas Diesler
>            Assignee: Claus Ibsen
>
> There are a number of issues with the Container API that make it unusable in 
> WildFly
> # Concept of unsynchronised singleton
> # Call to 3rd party code with partially constructed objects
> # Unsynchronised access to a shared resource
> Currently there are at least two components that compete for the Container 
> singleton. The Camel Subsystem and Insight Camel.
> I suspect that the Container API cannot be fixed in a compatible way. 
> Instead the notion of a CamelContextRegistry that fixes the issues with 
> Container may need to get added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to