Thanks for the feedback Matt - I’ve dealt with suspending the CamelContext when services aren’t available in a couple of ways. One way was to watch for the BlueprintEvent.WAITING, and suspend the camel context when that was received. This was a little problematic though because I don’t get another BlueprintEvent once the service is satisfied so I can resume the CamelContext. I hacked one up that just listened for new service registrations and tried to resume the context when it receive one, but that didn’t work very well.
The other method I tried was to use a Blueprint reference-listener on the service references. I didn’t complete this prototype, but it was actually working very well. I could suspend the CamelContext when the unbind method was called, and resume it when the bind method was called. This nice thing about this approach was I could detect service swaps as well, and I could restart the CamelContext if required - this worked well for JMS ConnectionFactory service references. As far at the startup goes, I also think the right time to start the CamelContext is when the BlueprintEvent.CREATED is received. I also think the CamelContext should be stopped when the BlueprintEvent.DESTROYING is received. I’ve got a PR out there for CAMEL-9570 that implements this startup behavior. If you have time, I’d really appreciate it if you could take a look and offer any suggestions - I haven’t heard anything on that PR. > On Nov 16, 2016, at 7:54 PM, Matt Pavlovich <[email protected]> wrote: > > > 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 >> >> >> >
