On 05/12/2007, dlaidlaw <[EMAIL PROTECTED]> wrote: > I am attempting to adapt Camel as a message mediator in my server-side > application. The application consumes messages from a JMS queue, passing the > message through various mediations, and finally calling the application > logic. A quite simple pipeline pattern. > > The application is OSGi-based, and components of the application may start > and stop dynamically. Each component has a queue associated with it, and > each of those may require a different pipeline of mediations.
How do you start and stop components? Starting and stopping bundles? > So the problem I see so far is that there is not really a way to dynamically > stop a route. I can add a route easily enough using the CamelContext > interface. The route is real easy to define with the mediations. But there > is no way to stop a route once it is activated. I can see that a Route is > defined as an endpoint and an ordered list of Services. The Service > interface does have a stop() method. Great, but the endpoint does not. If > the endpoint is a JMS endpoint (backed by the spring > DefaultMessageListenerContainer) then that really does need to be stopped! I > guess endpoints need a life cycle. > > Then, there needs to be a method to remove routes from the context. Perhaps > removing a route should stop the route as well, and stop and dispose > anything associated with the route. > > Adding the life cycle to the component is also nice. Stopping a component > should stop all endpoints it ever created. But the endpoint needs a life > cycle of its own. The endpoint life cycle could be controlled by the > component (component.stopEndpoint(Endpoint) or component.stopEndpoint(String > uri)). > > I can't see how I can use camel in the OSGi environment without this > feature. I know ServiceMix4 is OSGi based and supports Camel. How is this > handled there? So in the ServiceMix 4 runtime you create a bundle for a set of routes, then you can deploy & hot-reploy and undeploy at the bundle level. So the entire CamelContext is redeployed in one go. Then you can just create a bundle / spring.xml per redeployment unit. We also need to be able to do more finely grained stopping/starting/redploying - but the simplest level of granularity is always gonna be at the OSGi bundle level. The same is true for writing arbitrary Spring stuff; its kinda complex re-deploying a bean - but its easy to do it at the bundle / spring.xml level. BTW I think an Endpoint implement can implement Service if it wants (AFAIK) - though most of the time the things which are started & stopped are the Components themselves, then the Producer and Consumers on an Endpoint; usually an Endpoint object is often like a JMS Destination - by itself it doesn't do a whole lot until someone creates a Producer or Consumer - but if you've a use case am sure we could make them Services more often. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
