Boy you guys are fast =) Yes, we start and stop components by starting and stopping bundles. A component would be something like a purchasing module in the application. It contains its own business logic, persistence, etc. and exposes an interface as an OSGi service. Most of the interaction with the service is via JMS messages.
So when the purchasing component is started, I want to add routing for it. There is configuration I can consult to see what mediations are required on the JMS messages arriving on the purchasing queue. I am thinking of making this a list of URIs that can match to camel so this is real easy to do. Note that the routing and mediation are not part of the service that is exposed, but in another bundle with a service tracker tracking all of our application components and starting/stopping JMS listeners for them. We have this working today, using the standard spring DefaultMessageListenerContainer, not Camel. I am looking into Camel as a means to provide a mediation engine for this environment. So far I have been thinking there is only one CamelContext in my OSGi container, and I add and remove routes to/from it as components come and go. But if the CamelContext is a light-weight enough object, there is no reason I cannot create one per component. This sounds easy enough to do and would give me the ability to destroy the whole context when a component is stopped (when its service is unregistered). Very interesting. I will try that out. Since the endpoint has no stop method, and the JMSEndpoint certainly has none (I checked) I assume that stopping the CamelContext will cleanly stop the consumer. I'll know soon enough. Thanks James! -Don James.Strachan wrote: > > 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 > > -- View this message in context: http://www.nabble.com/Dynamically-changing-routes-%28OSGi%29-tf4951904s22882.html#a14180297 Sent from the Camel - Users mailing list archive at Nabble.com.
