camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
Subject Re: "cxf" name conflict in the spring context
Date Fri, 30 May 2008 09:39:48 GMT
Hi Willem,

Is this issue get resolved?

When I try to use camel-cxf component in smx4, I still get exceptions like
 Exception in thread "SpringOsgiExtenderThread-9" 
org.apache.camel.ResolveEndpointFailedException: Failed to resolve 
endpoint: cxf:bean:routerEndpoint due to: 
org.apache.camel.RuntimeCamelException: Could not auto create component: cxf
        at 
org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:262)
        at 
org.apache.camel.util.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:52)
        at 
org.apache.camel.model.RouteType.resolveEndpoint(RouteType.java:90)
        at 
org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:98)
        at 
org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:104)
        at org.apache.camel.model.FromType.resolveEndpoint(FromType.java:67)
        at 
org.apache.camel.impl.DefaultRouteContext.getEndpoint(DefaultRouteContext.java:73)
        at org.apache.camel.model.RouteType.addRoutes(RouteType.java:204)
        at org.apache.camel.model.RouteType.addRoutes(RouteType.java:81)
        at 
org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:451)
        at 
org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:443)
        at 
org.apache.camel.spring.SpringCamelContext.doStart(SpringCamelContext.java:149)
        at 
org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:47)
        at 
org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:103)
        at 
org.springframework.context.event.SimpleApplicationEventMulticaster$1.run(SimpleApplicationEventMulticaster.java:78)
        at 
org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:49)
        at 
org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:76)
        at 
org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:275)
        at 
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:737)
        at 
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.finishRefresh(AbstractDelegatedExecutionApplicationContext.java:271)
        at 
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:254)
        at 
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:136)
        at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.camel.RuntimeCamelException: Could not auto create 
component: cxf
        at 
org.apache.camel.impl.DefaultCamelContext.getComponent(DefaultCamelContext.java:149)
        at 
org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:233)
        ... 22 more
Caused by: java.lang.IllegalArgumentException: Bean with name: cxf in 
registry is not a Component: org.apache.cxf.bus.CXFBusImpl@3ca56f
        at 
org.apache.camel.osgi.OsgiComponentResolver.resolveComponent(OsgiComponentResolver.java:167)
        at 
org.apache.camel.impl.DefaultCamelContext.getComponent(DefaultCamelContext.java:138)
        ... 23 more

I guess it's same problem with this thread. I create jira [1] to track it.
Btw, I'm using camel 1.4-SNAPSHOT
[1]https://issues.apache.org/activemq/browse/CAMEL-563

Thanks

Freeman

Willem Jiang wrote:
> Hi James,
>
> I agree to look up the component with URI schema and component type to 
> avoid getting the wrong bean instance from the Spring Application 
> context.
> I went through the code and stack trace in the "Camel CXF Spring 
> Tomcat configuration" again, the exception is thrown from checking the 
> bean's type is not the instance of the Component.
>
> So the fixing could be more easier, if the bean's type is not match 
> with the component that we want , we just keep on searching the 
> component factory with the URI schema and do not throw the 
> IllegalArgumentException.
>
> In this way , we could still give a chance to user to override the 
> component schema definition in spring context.
>
> Willem
>
> James Strachan wrote:
>> On 12/02/2008, Willem Jiang <willem.jiang@gmail.com> wrote:
>>  
>>> Hi ,
>>>
>>> In the thread "Camel CXF Spring Tomcat configuration" , Aswin told us a
>>> conflict of "cxf" between the camel-cxf component and CXF default 
>>> bus in
>>> the same spring context. It will cause CXF internal component injection
>>> error.
>>>
>>> I think it is a common scenario when the user configure cxf default bus
>>> and setup the camel context in the same spring configuration file. To
>>> avoid this conflict we need to rename the camel-cxf components name or
>>> rename the cxf default bus name.
>>>
>>> Since the CXF default bus use the  "cxf"  name for a long time, lots of
>>> internal components in CXF will search for the "cxf " bus for 
>>> dependency
>>> injection, I suggest we rename the camel-cxf component name form "cxf"
>>> to "cxf_component" and we support to get the component with a short 
>>> name
>>> "cxf" in the ComponentResolver implementor.
>>>
>>> In this way, we could still support user to use the URI like "cxf://*"
>>> to create the cxf endpoint.
>>>
>>> Any thoughts?
>>>     
>>
>> Its unfortunate :(.
>>
>> How about we fix the ComponentResolver so that if there's a bean
>> called 'cxf' and its not a Component we just ignore it - writing some
>> DEBUG logging that we ignore it; then look for scheme + "Component"
>> instead.
>>
>> i.e. we look for "cxf" first, then if thats not a Component we look
>> for "cxfComponent"?
>>
>> I was wondering BTW if we should change the ComponentResolver so that
>> if it knew that the type of Component for "cxf" was
>> "org.apache.camel.component.cxf.CxfComponent" we'd look to see if
>> there was one single CxfComponent configured in the Spring context -
>> and if there was just one then use that.
>>
>> i.e. so it wouldn't actually matter what the component was registered
>> as. This would help fix issues like the recent thread on JMS
>> transaction issues...
>> http://www.nabble.com/Bug--to15351379s22882.html
>>
>>   
>
>


Mime
View raw message