> On 29 Oct 2014, at 11:20, Claus Ibsen <claus.ib...@gmail.com> wrote: > > On Wed, Oct 29, 2014 at 11:00 AM, Thomas Diesler <tdies...@redhat.com> wrote: >> Folks, >> >> for the WildFly/Camel <http://tdiesler.gitbooks.io/wildfly-camel/content/> >> 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 >> <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) ’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. >> > > 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.
Is it really conceptually correct that the context name can be changed at any time? The implementation could also be such that the name can only be set once. It could also be such that the contexts that extend DefaultCamelContext (and are already part of the code base) provide a name at construction time. This would provide the much wanted guarantee that a context has an immutable identity that can be used as a key into any map that maintains contexts. > > > > >> 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? >> > > 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. This SPI is broken because it calls into 3rd part code from a non-final constructor. The 3rd party provided Container sees a partially constructed object (e.g. a SpringCamelContext without the spring ApplicationContext initialised). > > http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/management/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/support/EventNotifierSupport.html > > You then register your event notifier on the camel context > > context.getManagementStrategy().addEventNotifier(myNotifier); > > >> cheers >> —thomas > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > Email: cib...@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/
