camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Diesler <>
Subject [CAMEL-7969] Container sees Context prematurely (with default name)
Date Wed, 29 Oct 2014 10:00:19 GMT

for the WildFly/Camel <> integration
I’m looking for the general notion of a CamelContextRegistry. This would be an SPI extension
point that allows retrieval of a registered CamelContext identified by some id. Ideally, the
registry would contain all CamelContexts regardless what API (i.e. spring, cdi, dsl) is used.
Instances of (or extending) DefaultCamelContext should be registered automatically.

There is already a starting point for that - the Container <>.
It has however a number of issues (CAMEL-7968 <>
 CAMEL-7969 <>)

One of my key questions would be about the identity of a CamelContext. The closest I could
find is the (mutable) ’name’ property. Because of its mutability and possible unavailability
after construction time, it is not a good identity. As a result, 3rd party code is being called
with a partially constructed CamelContext without defined name property. Uniqueness of CamelContext
name is also an issue, because not enforced.

I’d like to propose to make the CamelContext name immutable. It can probably still be initialed
lazy, but only once. For compatibility reasons it could write a warning in the 2.x series
and be properly enforced in 3.x. The existing  extensions (i.e. spring, cdi, osgi) could properly
construct the DefaultCamelContext with a given name. 

Calls to the Container API would need to get fixed such that 3rd party only sees fully constructed
instances. If this is not possible to do in a compatible way, one could deprecate the Container
API and make a CamelContextRegistry part of camel-core. 3rd party would then be registering
listeners with the registry, instead of providing a singleton Container as it is now.

What do you think?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message