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 <[EMAIL PROTECTED]> 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
