You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Daniel Kulp <dk...@apache.org> on 2010/06/25 01:47:56 UTC
Use of Endpoint.INTERFACE_NAME
I'm trying to track down some issues resolving endpoints and need some
clarification on the use of the Endpoint.INTERFACE_NAME (and SERVICE_NAME)
properties on the Endpoints.
In SOME places, these values are set as QNames. Examples:
org/apache/servicemix/nmr/spring/ReferenceFactory
the cxf-transport-nmr
Other places are setting it as a String:
DeliveryChannelImpl
ComponentContextImpl
etc...
The problem is the lookups aren't working if the endpoint was registered with
QNames (like a cxf endpoint using NMR transport), but the lookup is looking
based on Strings (http component passing through DeliveryChannelImpl).
What is the "correct" interpretation? I'll submit a patch for whatever needs
to be done, but I'd like to know the correct version.
The other option is to update the PropertyMatchingReference.match method to do
a "toString" if one of the values is a string.
Thoughts?
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Use of Endpoint.INTERFACE_NAME
Posted by Daniel Kulp <dk...@apache.org>.
Looking into it some more, it looks like there are a couple other places that
are assuming the property values are strings. Thus, I think this is a bug in
the cxf NMR transport (and the ReferenceFactory). I'll log a bug.
Dan
On Thursday 24 June 2010 7:47:56 pm Daniel Kulp wrote:
> I'm trying to track down some issues resolving endpoints and need some
> clarification on the use of the Endpoint.INTERFACE_NAME (and SERVICE_NAME)
> properties on the Endpoints.
>
> In SOME places, these values are set as QNames. Examples:
> org/apache/servicemix/nmr/spring/ReferenceFactory
> the cxf-transport-nmr
>
> Other places are setting it as a String:
> DeliveryChannelImpl
> ComponentContextImpl
> etc...
>
> The problem is the lookups aren't working if the endpoint was registered
> with QNames (like a cxf endpoint using NMR transport), but the lookup is
> looking based on Strings (http component passing through
> DeliveryChannelImpl).
>
> What is the "correct" interpretation? I'll submit a patch for whatever
> needs to be done, but I'd like to know the correct version.
>
> The other option is to update the PropertyMatchingReference.match method to
> do a "toString" if one of the values is a string.
>
> Thoughts?
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog