camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bengt Rodehav (JIRA)" <>
Subject [jira] Commented: (CAMEL-3350) Camel context not started although the start() method succeeded
Date Mon, 22 Nov 2010 18:03:25 GMT


Bengt Rodehav commented on CAMEL-3350:

Claus, I have now tested your fix in trunc. Yes, setting a name of null now causes an exception
to be thrown - in that respect it works.

However, I still need a safe way to know that I succeeded in starting the camel context. Now
that you eliminated this problem
(setting the name to null), does that mean that an exception will always be thrown if the
context could not be started? Or,
conversely, if a call to CamelContext.start() returns without throwing an exception, does
that mean that I managed to start the

Also, it shouldn't be possible for the camel context to report that it is started while JMX
does not show the context and
when in fact it didn't succeed. To me it seems like this issue isn't really resolved yet -
unless setting the name to null was the only
thing that could possibly cause this situation.

> Camel context not started although the start() method succeeded
> ---------------------------------------------------------------
>                 Key: CAMEL-3350
>                 URL:
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.5.0
>            Reporter: Bengt Rodehav
>            Assignee: Claus Ibsen
>             Fix For: 2.6.0
> I accidentally set the name of the context to null. and got the exception below:
> \\
> \\
> {code}
> 2010-11-17 11:32:34,456 | WARN  | guration Updater | DefaultCamelContext            
 | e.camel.impl.DefaultCamelContext 1278 | Cannot start lifecycle strategy:
This strategy will be removed. Cause: java.lang.NullPointerException
> org.apache.camel.RuntimeCamelException: java.lang.NullPointerException
> 	at org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(
> 	at
> 	at org.apache.camel.impl.DefaultCamelContext.doStartCamel(
> 	at org.apache.camel.impl.DefaultCamelContext.doStart(
> 	at org.apache.camel.impl.ServiceSupport.start(
> 	at org.apache.camel.impl.ServiceSupport.start(
> 	at org.apache.camel.impl.DefaultCamelContext.start(
> 	at se.digia.connect.core.service.RouteServiceBase.doStart(
> 	at se.digia.connect.core.service.ServiceBase.start(
> 	at
> 	at
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.6.0_07]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke([:1.6.0_07]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke([:1.6.0_07]
> 	at java.lang.reflect.Method.invoke([:1.6.0_07]
> 	at[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT]
> 	at[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT]
> 	at[77:org.apache.felix.ipojo:1.7.0.SNAPSHOT]
> 	at org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__stateChanged([77:org.apache.felix.ipojo:1.7.0.SNAPSHOT]
> 	at org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged([77:org.apache.felix.ipojo:1.7.0.SNAPSHOT]
> 	at org.apache.felix.ipojo.InstanceManager.setState([77:org.apache.felix.ipojo:1.7.0.SNAPSHOT]
> 	at org.apache.felix.ipojo.InstanceManager.start([77:org.apache.felix.ipojo:1.7.0.SNAPSHOT]
> 	at org.apache.felix.ipojo.InstanceManager.reconfigure([77:org.apache.felix.ipojo:1.7.0.SNAPSHOT]
> 	at org.apache.felix.ipojo.IPojoFactory.reconfigure([77:org.apache.felix.ipojo:1.7.0.SNAPSHOT]
> 	at org.apache.felix.ipojo.IPojoFactory.updated([77:org.apache.felix.ipojo:1.7.0.SNAPSHOT]
> 	at$[5:org.apache.felix.configadmin:1.2.4]
> 	at[5:org.apache.felix.configadmin:1.2.4]
> Caused by: java.lang.NullPointerException
> 	at[:1.6.0_07]
> 	at
> 	at
> 	... 25 more
> {code}
> \\
> The above exception was however caught and not rethrown which fooled me to believe that
the context was successfully started while it in fact wasn't.
> Immediately after the call to the context's start() method I check if the context is
started using the getStatus() method. It is then reported as started despite the fact that
it failed (due to the exception above).
> I then 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 was successfully started
or not.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message