I created a JIRA ticket for this: https://issues.apache.org/activemq/browse/CAMEL-3350
<https://issues.apache.org/activemq/browse/CAMEL-3350>/Bengt 2010/11/19 Bengt Rodehav <[email protected]> > I have now tried the approach I described in my previous post. After my > call to start the context has returned, I check if the context is started > using the getStatus() method. Unfortunately the context is reported as > started despite the fact that it failed (due to the exception I listed). > > I started jconsole to see via JMX if the context is considered to be > started but it's not. Sounds a lot like a bug to me. There should be a safe > (and simple) way to find out (after having attempted to start the context) > whether the context is started or not. > > BTW, I looked at the fix you did in revision 1 036 382. The fix makes sense > but it was done in the DefaultCamelContextNameStrategy class but I think the > exception I got was from the getObjectNameForCamelContext() method in > the DefaultManagementNamingStrategy class. Maybe the same fix needs to be > done in more than one place? > > However, like I wrote before, it's OK to get a NPE if I deliberately set > the name of the context to null as long as I can find out whether I > succeeded in starting the context or not. > > /Bengt > > > > 2010/11/19 Bengt Rodehav <[email protected]> > > Hello Claus - thanks for your reply. >> >> I've tested the latest from trunk and I still get the NPE. However, I'm >> not exactly sure what you have fixed. >> >> My problem (which was self inflicted since it was a bug in another part of >> the system) was that I accidentally set the name of the camel context to >> null. That's why the NPE was thrown. An NPE is OK by me but the problem was >> that it was caught and not rethrown. The result was that my application >> thought that the context was started while, in fact, it was not. >> >> Was your fix an attempt to not throw an NPE when the name of the context >> is null or was the fix to make sure that it was rethrown? >> >> Judging from you previous post, it seems like not rethrowing is as >> designed. My problem then is how do I make sure that the starting of the >> context worked? Currently my code goes like this: >> >> try { >> mCamelContext.start(); >> } catch (Exception e) { >> <Handle error> >> } >> >> What then is best practice to make sure that the context was started? Is >> it as easy as: >> >> boolean isStarted = false; >> try { >> mCamelContext.start(); >> isStarted = mCamelContext.getStatus().isStarted(); >> } catch (Exception e) { >> <Log error> >> } >> if(!isStarted) { >> <Handle error> >> } >> >> I have just assumed that if the start() method is executed without >> exceptions then the context is started. This seems like a faulty assumption. >> >> /Bengt >> >> >> 2010/11/18 Claus Ibsen <[email protected]> >> >> Hi >>> >>> I commit a fix for the NPE in camel-core, trunk: 1036382. >>> >>> It would be nice if you could test that with your issue. >>> >>> >>> On Thu, Nov 18, 2010 at 10:04 AM, Claus Ibsen <[email protected]> >>> wrote: >>> > On Thu, Nov 18, 2010 at 8:43 AM, Bengt Rodehav <[email protected]> >>> wrote: >>> >> Anyone have an opinion about this? Shall I create a JIRA ticket? >>> >> >>> > >>> > This is on purpose as the host container may deny starting/using the >>> > lifecycle strategy. >>> > For example deny using JMX etc. And Camel will just fallback and >>> > continue to book up without that strategy. >>> > >>> > The NPE you are facing is obviously related to the complexity of the >>> > OSGi platform. So yeah open a ticket and lets see if we can nail this >>> > problem. >>> > >>> > >>> > >>> > >>> > >>> >> /Benke >>> >> >>> >> 2010/11/17 Bengt Rodehav <[email protected]> >>> >> >>> >>> I've encountered some problems regarding starting Camel. I use Camel >>> 2.5.0. >>> >>> I also use iPOJO in Karaf to create OSGi services. When my iPOJO >>> instance >>> >>> becomes valid, my callback method is started and I try to create a >>> Camel >>> >>> context and start it. >>> >>> >>> >>> However, even if I fail to start Camel, no exception is thrown which >>> causes >>> >>> me problems later on. When looking through the code it seems like an >>> >>> exception is caught but not rethrown in >>> DefaultCamelContext.doStartCamel() >>> >>> on line 1270. Is this "as designed" or a bug? I would really like an >>> >>> exception to be thrown at this point to allow me to know whether I >>> succeeded >>> >>> in starting the context or not. >>> >>> >>> >>> In my particular case, I have erroneously set the name of the camel >>> context >>> >>> to null. >>> >>> >>> >>> The exception I get is the following: >>> >>> >>> >>> 2010-11-17 11:32:34,456 | WARN | guration Updater | >>> DefaultCamelContext >>> >>> | e.camel.impl.DefaultCamelContext 1278 | Cannot start >>> lifecycle >>> >>> strategy: >>> >>> >>> org.apache.camel.management.defaultmanagementlifecyclestrat...@1060ee9.thisstrategy >>> will be removed. Cause: java.lang.NullPointerException >>> >>> org.apache.camel.RuntimeCamelException: >>> java.lang.NullPointerException >>> >>> at >>> >>> >>> org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1140) >>> >>> at >>> >>> >>> org.apache.camel.management.DefaultManagementLifecycleStrategy.onContextStart(DefaultManagementLifecycleStrategy.java:161) >>> >>> at >>> >>> >>> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1270) >>> >>> at >>> >>> >>> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1213) >>> >>> at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:65) >>> >>> at >>> org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:52) >>> >>> at >>> >>> >>> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1191) >>> >>> at >>> >>> >>> se.digia.connect.core.service.RouteServiceBase.doStart(RouteServiceBase.java:51) >>> >>> at >>> se.digia.connect.core.service.ServiceBase.start(ServiceBase.java:50) >>> >>> at >>> >>> >>> se.digia.connect.services.skandia.filetransfer.FileTransferService.__start(FileTransferService.java:63) >>> >>> at >>> >>> >>> se.digia.connect.services.skandia.filetransfer.FileTransferService.start(FileTransferService.java) >>> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method)[:1.6.0_07] >>> >>> at >>> >>> >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)[:1.6.0_07] >>> >>> at >>> >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)[:1.6.0_07] >>> >>> at java.lang.reflect.Method.invoke(Method.java:597)[:1.6.0_07] >>> >>> at >>> >>> >>> org.apache.felix.ipojo.util.Callback.call(Callback.java:237)[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT] >>> >>> at >>> >>> >>> org.apache.felix.ipojo.util.Callback.call(Callback.java:193)[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT] >>> >>> at >>> >>> >>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.call(LifecycleCallback.java:86)[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT] >>> >>> at >>> >>> >>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__stateChanged(LifecycleCallbackHandler.java:162)[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT] >>> >>> at >>> >>> >>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT] >>> >>> at >>> >>> >>> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441)[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT] >>> >>> at >>> >>> >>> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT] >>> >>> at >>> >>> >>> org.apache.felix.ipojo.InstanceManager.reconfigure(InstanceManager.java:1169)[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT] >>> >>> at >>> >>> >>> org.apache.felix.ipojo.IPojoFactory.reconfigure(IPojoFactory.java:481)[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT] >>> >>> at >>> >>> >>> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:648)[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT] >>> >>> at >>> >>> >>> org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1460)[5:org.apache.felix.configadmin:1.2.4] >>> >>> at >>> >>> >>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)[5:org.apache.felix.configadmin:1.2.4] >>> >>> Caused by: java.lang.NullPointerException >>> >>> at >>> javax.management.ObjectName.quote(ObjectName.java:1846)[:1.6.0_07] >>> >>> at >>> >>> >>> org.apache.camel.management.DefaultManagementNamingStrategy.getObjectNameForCamelContext(DefaultManagementNamingStrategy.java:95) >>> >>> at >>> >>> >>> org.apache.camel.management.DefaultManagementLifecycleStrategy.onContextStart(DefaultManagementLifecycleStrategy.java:128) >>> >>> ... 25 more >>> >>> >>> >>> /Bengt >>> >>> >>> >> >>> > >>> > >>> > >>> > -- >>> > Claus Ibsen >>> > ----------------- >>> > FuseSource >>> > Email: [email protected] >>> > Web: http://fusesource.com >>> > Twitter: davsclaus >>> > Blog: http://davsclaus.blogspot.com/ >>> > Author of Camel in Action: http://www.manning.com/ibsen/ >>> > >>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> FuseSource >>> Email: [email protected] >>> Web: http://fusesource.com >>> Twitter: davsclaus >>> Blog: http://davsclaus.blogspot.com/ >>> Author of Camel in Action: http://www.manning.com/ibsen/ >>> >> >> >
