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 ( https://issues.apache.org/jira/browse/CAMEL-9570 <https://issues.apache.org/jira/browse/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 registered. 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
