Hi I have implemented an improvement on trunk.
On Sat, Nov 20, 2010 at 6:42 PM, Bengt Rodehav <[email protected]> wrote: > 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/ >>>> >>> >>> >> > -- 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/
