camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Pavlovich <>
Subject Re: Proposed change to BlueprintCamelContext startup behaviour
Date Thu, 17 Nov 2016 02:54:43 GMT

I've had to work through these same issues by registering a service 
listener to a "service manager" thingie and having the CamelRoute passed 
into the "service manager" thingie.

However, shouldn't the CamelContext be initialized when the 
BlueprintEvent.CREATED is sent? I could see it being problematic to know 
when the Context is done, since tCREATED the last BlueprintEvent.

Perhaps implementing a standard service manager that you could register 
a list of services and a context would be a better approach?

On 11/10/16 11:24 AM, Quinn Stevenson wrote:
> I’d like to propose changing the BlueprintCamelContext such that the Camel Context
is started when the Blueprint container is fully created.
> While working on CAMEL-9570 ( <>
), I noticed that the BlueprintCamelContext implements the OSGi ServiceLister interface and
starts the Camel Context when it is notified that the BlueprintContainer service has been
> However, I’ve hit some problems with this behavior when there are issues with creation/initialization
of some of the camel components.  (NOTE - I caused these issues with my experiments, but the
current startup behavior made them much more difficult to debug ).
> I’d like to change the BlueprintCamelContext so that the Camel Context is started when
it receives the BlueprintEvent.CREATED for the blueprint container, and also stop the Camel
Context when it receives the BlueprintEvent.DESTROYING for the blueprint container.
> BTW - This will also set the stage for another improvement I have in mind, where the
BlueprintCamelContext will automatically suspend if an OSGi Service isn’t available, and
resume once the service is available again.
> If this sounds OK to the community, I’ll create a JIRA and a PR

View raw message