Hi Daniel, It sounds good. I will take care of the patch today.
-- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: willemjiang On Tuesday, October 23, 2012 at 3:02 AM, Daniel Gredler wrote: > Hi all, > > After digging through the code, it appears to me that the changes can be > confined to ManagedCamelContextMBean and ManagedCamelContext, which is > much less invasive than what I had thought. > > I've created a feature request to add support for cold restarts via JMX, > and have attached a proposed patch: > > https://issues.apache.org/jira/browse/CAMEL-5734 > > It's fairly small; I'd be grateful if someone could take a couple of > minutes to have a look. > > Thanks! > > Daniel > > > -----Original Message----- > From: Daniel Gredler [mailto:dgred...@dhlglobalmail.com] > Sent: Friday, October 19, 2012 3:52 PM > To: dev@camel.apache.org (mailto:dev@camel.apache.org) > Subject: Camel cold restart via JMX > > Hi guys, > > I was thinking about creating a feature request, but it involves such a > fundamental aspect of Camel that I thought I'd ask here first. > > I have a situation where I'd like to do a cold restart on a Camel > context (context.stop(), and then context.start()). The catch is that I > want to do this via JMX, and when the Camel context is stopped, the JMX > service goes down and obviously I can't issue the start() request. > > I was thinking that it would be nice to have a restart() method on the > Camel context (defined as the equivalent of stop + start), possibly even > in the Service interface which defines the start() and stop() methods. > This would allow the Camel context to go down and come back up without > requiring a second start() request, which is nice when the start() > request is impossible. > > Is it worth creating the feature request? Am I missing something that > obviates the need for such a feature? Or is the use case so narrow that > it doesn't really make sense to add? Let me know what you think... > > Take care, > > Daniel
