[
https://issues.apache.org/jira/browse/CAMEL-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9657:
-------------------------------
Issue Type: Improvement (was: Bug)
> Problems with DefaultCamelContext constructor calling
> Container.Instance.manage()
> ----------------------------------------------------------------------------------
>
> Key: CAMEL-9657
> URL: https://issues.apache.org/jira/browse/CAMEL-9657
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: James Netherton
>
> [This
> code|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/impl/DefaultCamelContext.java#L300]
> can cause problems when Camel runs in a container (like WildFly) with CDI.
> The code assumes that the camel context will get started and stopped at some
> point during its lifecycle, which then triggers an
> [unmanage|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/impl/DefaultCamelContext.java#L3151]
> from the Container instance object.
> With CDI, this scenario may not happen. Especially when CDI proxies are
> created for @Injecting camel contexts into beans. The camel context in this
> scenario is never started or stopped, resulting in this [map of
> contexts|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/spi/Container.java#L51]
> filling up with redundant objects.
> Not sure what the best way of dealing with this is. It'd be nice to remove
> the Container.manage code from the DefaultCamelContext default constructor or
> implement Container in such a way that clients can override its behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
