Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of tdiesler@redhat.com designates
 209.132.183.28 as permitted sender)
From: Thomas Diesler <tdiesler@redhat.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_3AD039CC-4F18-4A53-9103-D77BBF4C7877"
Date: Wed, 29 Oct 2014 11:00:19 +0100
Subject: [CAMEL-7969] Container sees Context prematurely (with default name)
To: dev@camel.apache.org
Message-Id: <F88FDBA2-39AE-47BF-8395-4F5A1AB12D44@redhat.com>
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))

--Apple-Mail=_3AD039CC-4F18-4A53-9103-D77BBF4C7877
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Folks,

for the WildFly/Camel =
<http://tdiesler.gitbooks.io/wildfly-camel/content/> integration I=E2=80=99=
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 =
<https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/=
apache/camel/spi/Container.java>. It has however a number of issues =
(CAMEL-7968 <https://issues.apache.org/jira/browse/CAMEL-7968>  =
CAMEL-7969 <https://issues.apache.org/jira/browse/CAMEL-7969>)

One of my key questions would be about the identity of a CamelContext. =
The closest I could find is the (mutable) =E2=80=99name=E2=80=99 =
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=E2=80=99d 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.=20

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?

cheers
=E2=80=94thomas=

--Apple-Mail=_3AD039CC-4F18-4A53-9103-D77BBF4C7877--