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] [Comment Edited] (CAMEL-8000) Add global notion of CamelContextRegistry
Date Mon, 17 Nov 2014 14:13:34 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-8000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14214676#comment-14214676
] 

Thomas Diesler edited comment on CAMEL-8000 at 11/17/14 2:13 PM:
-----------------------------------------------------------------

The clear() shadows an issue with insufficiently defined context lifecycle. 

AFAICS, a CamelContext is owned by the client that creates it. The client therefore also controls
the (softly defined) identity and the sharing. The context ends life when the client does
no longer hold a reference to it. A call to CamelContext.stop() is optional.

We are now trying to introduce an entity that has a lifecycle that outlives individual contexts
and (although it does not own them) holds references to them. To model this properly, we would
probably want to have something like a CamelRuntime - similar to Framework and Bundle in OSGi.
The runtime is the owner of all contexts, it provides a view of all registered contexts, it
can be queried and possibly own other constructs that are applicable to multiple contexts
(i.e. defaults for newly created contexts). This would be a larger change to camel and probably
requires a lot more thought.

CamelContextRegistry.clear() is still wrong, but it is also wrong to assume that a context
gets an non-optional call to CamelContext.stop() which ends its life. 

The registry probably needs to hold weak references, to avoid hogging of stale contexts.


was (Author: tdiesler):
The clear() shadows an issue with insufficiently defined context lifecycle. 

AFAICS, a CamelContext is owned by the client that creates it. The client therefore also controls
the (softly defined) identity and the sharing. The context ends life when the client does
no longer hold a reference to it. A call to CamelContext.stop() is optional.

We are now trying to introduce an entity that has a lifecycle that outlives individual context
and (although it does not own them) holds references to them. To model this properly, we would
probably want to have something like a CamelRuntime - similar to Framework and Bundle in OSGi.
The runtime is the owner of all contexts, it provides a view of all registered contexts, it
can be queried and possibly own other constructs that are applicable to multiple contexts
(i.e. defaults for newly created contexts). This would be a larger change to camel and probably
requires a lot more thought.

CamelContextRegistry.clear() is still wrong, but it is also wrong to assume that a context
gets an non-optional call to CamelContext.stop() which ends its life. 

The registry probably needs to hold weak references, to avoid hogging of stale contexts.

> 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
>             Fix For: 2.15.0
>
>
> 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)

Mime
View raw message