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 claus.ibsen@gmail.com
 designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <F88FDBA2-39AE-47BF-8395-4F5A1AB12D44@redhat.com>
References: <F88FDBA2-39AE-47BF-8395-4F5A1AB12D44@redhat.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Wed, 29 Oct 2014 11:20:41 +0100
Message-ID: 
 <CAGB5yN=+v7Tt9t9iiX=B7sD+o9gPzpLPoajsXBH0Pm5UcY2ReA@mail.gmail.com>
Subject: Re: [CAMEL-7969] Container sees Context prematurely (with default
 name)
To: dev <dev@camel.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 29, 2014 at 11:00 AM, Thomas Diesler <tdiesler@redhat.com> wrot=
e:
> Folks,
>
> for the WildFly/Camel <http://tdiesler.gitbooks.io/wildfly-camel/content/=
> integration I=E2=80=99m looking for the general notion of a CamelContextR=
egistry. This would be an SPI extension point that allows retrieval of a re=
gistered CamelContext identified by some id. Ideally, the registry would co=
ntain all CamelContexts regardless what API (i.e. spring, cdi, dsl) is used=
. Instances of (or extending) DefaultCamelContext should be registered auto=
matically.
>
> There is already a starting point for that - the Container <https://githu=
b.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/sp=
i/Container.java>. It has however a number of issues (CAMEL-7968 <https://i=
ssues.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. Th=
e closest I could find is the (mutable) =E2=80=99name=E2=80=99 property. Be=
cause of its mutability and possible unavailability after construction time=
, it is not a good identity. As a result, 3rd party code is being called wi=
th a partially constructed CamelContext without defined name property. Uniq=
ueness of CamelContext name is also an issue, because not enforced.
>
> I=E2=80=99d like to propose to make the CamelContext name immutable. It c=
an probably still be initialed lazy, but only once. For compatibility reaso=
ns 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 constr=
uct the DefaultCamelContext with a given name.
>

The idea is that a camel context can be configured anyway you want -
using getter/setter etc, DI, and whatnot.

And then its start() method is invoked when its ready to be used, and
it can do its initialization needed, such as setting up naming. As
Camel allows end users to not define any name, and Camel auto assigns
a name, or end users can define a naming pattern, which is used to
define the name etc.

So its not intended to provide a name in the constructor.


> Calls to the Container API would need to get fixed such that 3rd party on=
ly sees fully constructed instances. If this is not possible to do in a com=
patible way, one could deprecate the Container API and make a CamelContextR=
egistry part of camel-core. 3rd party would then be registering listeners w=
ith the registry, instead of providing a singleton Container as it is now.
>
> What do you think?
>

If you want to keep a list of all known CamelContext in a JVM, then
keep using the Container SPI hook, and then in the manage method, you
add an EventNotifier to the CamelContext, then that event notifier
will emit an event when the CamelContext is starting / started. So if
you listen for the started event, you have the name the context was
given.

http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/m=
anagement/event/package-frame.html

There is a support class you can extend which is easier
http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/s=
upport/EventNotifierSupport.html

You then register your event notifier on the camel context

context.getManagementStrategy().addEventNotifier(myNotifier);


> cheers
> =E2=80=94thomas


--=20
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/