You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Bengt Rodehav <be...@rodehav.com> on 2010/11/17 11:55:19 UTC
Exception caught but not rethrown in DefaultCamelContext.doStartCamel()
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.DefaultManagementLifecycleStrategy@1060ee9. This
strategy 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
Re: Exception caught but not rethrown in DefaultCamelContext.doStartCamel()
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I have implemented an improvement on trunk.
On Sat, Nov 20, 2010 at 6:42 PM, Bengt Rodehav <be...@rodehav.com> 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 <be...@rodehav.com>
>
>> 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 <be...@rodehav.com>
>>
>> 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 <cl...@gmail.com>
>>>
>>> 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 <cl...@gmail.com>
>>>> wrote:
>>>> > On Thu, Nov 18, 2010 at 8:43 AM, Bengt Rodehav <be...@rodehav.com>
>>>> 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 <be...@rodehav.com>
>>>> >>
>>>> >>> 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.DefaultManagementLifecycleStrategy@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: cibsen@fusesource.com
>>>> > 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: cibsen@fusesource.com
>>>> 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Exception caught but not rethrown in DefaultCamelContext.doStartCamel()
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <be...@rodehav.com>
> 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 <be...@rodehav.com>
>
> 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 <cl...@gmail.com>
>>
>> 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 <cl...@gmail.com>
>>> wrote:
>>> > On Thu, Nov 18, 2010 at 8:43 AM, Bengt Rodehav <be...@rodehav.com>
>>> 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 <be...@rodehav.com>
>>> >>
>>> >>> 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.DefaultManagementLifecycleStrategy@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: cibsen@fusesource.com
>>> > 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: cibsen@fusesource.com
>>> Web: http://fusesource.com
>>> Twitter: davsclaus
>>> Blog: http://davsclaus.blogspot.com/
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>
>>
>>
>
Re: Exception caught but not rethrown in DefaultCamelContext.doStartCamel()
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <be...@rodehav.com>
> 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 <cl...@gmail.com>
>
> 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 <cl...@gmail.com>
>> wrote:
>> > On Thu, Nov 18, 2010 at 8:43 AM, Bengt Rodehav <be...@rodehav.com>
>> 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 <be...@rodehav.com>
>> >>
>> >>> 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.DefaultManagementLifecycleStrategy@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: cibsen@fusesource.com
>> > 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: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>
>
>
Re: Exception caught but not rethrown in DefaultCamelContext.doStartCamel()
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <cl...@gmail.com>
> 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 <cl...@gmail.com>
> wrote:
> > On Thu, Nov 18, 2010 at 8:43 AM, Bengt Rodehav <be...@rodehav.com>
> 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 <be...@rodehav.com>
> >>
> >>> 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.DefaultManagementLifecycleStrategy@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: cibsen@fusesource.com
> > 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: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
Re: Exception caught but not rethrown in DefaultCamelContext.doStartCamel()
Posted by Claus Ibsen <cl...@gmail.com>.
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 <cl...@gmail.com> wrote:
> On Thu, Nov 18, 2010 at 8:43 AM, Bengt Rodehav <be...@rodehav.com> 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 <be...@rodehav.com>
>>
>>> 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.DefaultManagementLifecycleStrategy@1060ee9.This strategy 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: cibsen@fusesource.com
> 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Exception caught but not rethrown in DefaultCamelContext.doStartCamel()
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Nov 18, 2010 at 8:43 AM, Bengt Rodehav <be...@rodehav.com> 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 <be...@rodehav.com>
>
>> 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.DefaultManagementLifecycleStrategy@1060ee9.This strategy 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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Exception caught but not rethrown in DefaultCamelContext.doStartCamel()
Posted by Bengt Rodehav <be...@rodehav.com>.
Anyone have an opinion about this? Shall I create a JIRA ticket?
/Benke
2010/11/17 Bengt Rodehav <be...@rodehav.com>
> 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.DefaultManagementLifecycleStrategy@1060ee9.This strategy 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
>