Thanks for a great email Nicky... On 6/7/07, Nicky Sandhu <[EMAIL PROTECTED]> wrote:
Looking ahead to when camel would be in deployment some features are needed for management, monitoring Runtime Management/Monitoring 1.) A registry of contexts and the routes in them
I was thinking we'd mostly defer to Spring for this; so from Spring you could look up all the available CamelContext's registered - or look up one by name. Then Spring supports nested contexts & OSGi etc. Would that do the trick? Or were you thinking of some kinda uber-registry thats Camel specific? Another option is that each CamelContext exposes itself in JMX...
2.) JMX interface to this registry with ability to add/remove routes and start/stop contexts
Great idea. https://issues.apache.org/activemq/browse/CAMEL-4
3.) Ability to deploy a new route to a running context (once context is started can routes be added?)
Absolutely! We just need to expose the add/remove routes API to the MBeans (see above). You can already add a Route to a CamelContext whenever required.
4.) Ability to support restarts ie add/removing route to a running context should be persistent
In what way were you thinking? Updating the Spring XML? Or reading the rules from a database?
5.) Support for notification via JMX or something else when changes happen to a context
Yeah; I was thinking we should have a listener so as things change you can be notified of new endpoints/routes etc https://issues.apache.org/activemq/browse/CAMEL-5 https://issues.apache.org/activemq/browse/CAMEL-6
6.) Support for notification when errors happen during processing of a route message. (reminds me of cross-cutting requirement across some/all routes, AOP based??)
We support a pluggable ErrorHandler right now which you can specify on a CamelContext, a Route or part of a route/pipeline which allows you to do things like dead letter channel stuff, or notifying some component of all failures out of band to the retries etc etc. http://activemq.apache.org/camel/error-handler.html Would that do, or is there something else you had in mind?
There are two options available to maintaining multiple camel contexts in a running JVM 1.) WAR deployments to a J2EE container 2.) Bundle deployments to OSGi container Both these options provide the ability to have multiple camel contexts running without interferring with each other (class loading issues and such) Is there anything on the road maps to address these needs?
There's those JIRAs above - am sure we could do lots more as well. Lots of this I was hoping we could sit on top of just Spring or Spring + OSGi or deploy Camel inside JBI (ServiceMix) as a JBI component. i.e. so Camel doesn't have to do any container level things; it just works with containers like servlet engines, Spring, OSGi and JBI. But am sure we can do much better on the JMX side of things along with the tooling side of things. Plus testing more hot-deployment/reconfiguration of rules etc. -- James ------- http://macstrac.blogspot.com/
