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/ >> > >
