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