camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aki Yoshida (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-7344) Some endpoints configured using beans may result in NPE under DEBUG mode
Date Fri, 04 Apr 2014 22:09:15 GMT

     [ https://issues.apache.org/jira/browse/CAMEL-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aki Yoshida updated CAMEL-7344:
-------------------------------

    Description: 
CAMEL-6131 seems to have introduced this issue or more precisely speaking, it has made this
issue visible.

DefaultEndpoint's toString() method seems to require its endpoint string value to be set.
If it's not set, the toString method throws an exception. A fully built endpoint always has
its endpoint string value set, thus there is no issue. However, an endpoint being manually
set up may not have its endpoint string value set from the beginning (e.g., when its super
class uses the DefaultEndpoint's default constructor to instantiate using a bean based instantiation).

The debug log statement introduced in CAMEL-6131 invokes this toString method during the endpoint
setup.

That means, a spring based CXF endpoint may result in the following exception under the debug
mode.

SLF4J: Failed toString() invocation on an object of type [org.apache.camel.component.cxf.CxfSpringEndpoint]
java.lang.IllegalArgumentException: endpointUri is not specified and org.apache.camel.component.cxf.CxfSpringEndpoint
does not implement createEndpointUri() to create a default value
at org.apache.camel.impl.DefaultEndpoint.getEndpointUri(DefaultEndpoint.java:154)
at org.apache.camel.impl.DefaultEndpoint.toString(DefaultEndpoint.java:139)
at org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:304)
at org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276)
at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230)
at org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:271)
at org.apache.camel.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:528)
at org.apache.camel.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:570)
at org.apache.camel.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:454)
at org.apache.camel.util.EndpointHelper.setProperties(EndpointHelper.java:249)
at org.apache.camel.component.cxf.CxfEndpoint.setCamelContext(CxfEndpoint.java:840)

I  wonder whether we really need DefaultEndpoint's getEndpointUri() to throw an exception
when it's endpoint string value is not set. But if we keep this rule, we must catch the exception
in its toString() method so that we won't throw the above exception when this toString() method
is  called during the endpoint is being set up

.I would propose to do the catching in toString method. If we decide to change the getEndpointUri()
method to not throw the exception (that change probably will require the NPE check at the
users of this method), we can make that change and revert the exception catch of the toString.


> Some endpoints configured using beans may result in NPE under DEBUG mode
> ------------------------------------------------------------------------
>
>                 Key: CAMEL-7344
>                 URL: https://issues.apache.org/jira/browse/CAMEL-7344
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>    Affects Versions: 2.11.4, 2.12.3, 2.13.0
>            Reporter: Aki Yoshida
>            Assignee: Aki Yoshida
>
> CAMEL-6131 seems to have introduced this issue or more precisely speaking, it has made
this issue visible.
> DefaultEndpoint's toString() method seems to require its endpoint string value to be
set. If it's not set, the toString method throws an exception. A fully built endpoint always
has its endpoint string value set, thus there is no issue. However, an endpoint being manually
set up may not have its endpoint string value set from the beginning (e.g., when its super
class uses the DefaultEndpoint's default constructor to instantiate using a bean based instantiation).
> The debug log statement introduced in CAMEL-6131 invokes this toString method during
the endpoint setup.
> That means, a spring based CXF endpoint may result in the following exception under the
debug mode.
> SLF4J: Failed toString() invocation on an object of type [org.apache.camel.component.cxf.CxfSpringEndpoint]
> java.lang.IllegalArgumentException: endpointUri is not specified and org.apache.camel.component.cxf.CxfSpringEndpoint
does not implement createEndpointUri() to create a default value
> at org.apache.camel.impl.DefaultEndpoint.getEndpointUri(DefaultEndpoint.java:154)
> at org.apache.camel.impl.DefaultEndpoint.toString(DefaultEndpoint.java:139)
> at org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:304)
> at org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276)
> at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230)
> at org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:271)
> at org.apache.camel.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:528)
> at org.apache.camel.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:570)
> at org.apache.camel.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:454)
> at org.apache.camel.util.EndpointHelper.setProperties(EndpointHelper.java:249)
> at org.apache.camel.component.cxf.CxfEndpoint.setCamelContext(CxfEndpoint.java:840)
> I  wonder whether we really need DefaultEndpoint's getEndpointUri() to throw an exception
when it's endpoint string value is not set. But if we keep this rule, we must catch the exception
in its toString() method so that we won't throw the above exception when this toString() method
is  called during the endpoint is being set up
> .I would propose to do the catching in toString method. If we decide to change the getEndpointUri()
method to not throw the exception (that change probably will require the NPE check at the
users of this method), we can make that change and revert the exception catch of the toString.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message