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/07/22 03:23:09 UTC
Problem with servicemix-http and non-jbi registered endpoints....
I'm having a problem with the way servicemix-http interacts with endpoints
that aren't registered through JBI. In particular, the cxf-nmr registered
endpoints that register directly with the NMR.
The issue I'm having is that when trying to load/create a WSDL, it's not
finding the ServiceEndpoint to get the wsdl from. Digging into it, it seems
to be an issue with AbstractComponentContext.
When JBI based endpoints are registered, the ComponentContext adds an extra
property to property map of either "jbi.internal" or "jbi.external" with a
value of True. Endpoints not registered via JBI would not have those
properties added.
The problem is when servicemix-http queries, the AbstractComponentContext adds
"jbi.internal"/True to the properties to match on automatically. Since the
cxf-nmr Endpoint would not have added that property, the props don't match and
no endpoint is returned. Thus, no wsdl. Thus, things like determining if
an operation is one-way and such don't work.
There are a couple ways to approach this and I'd like some advice from the
"experts":
1) Have cxf-nmr add "jbi.internal" with it's properties. Kind of a hack
job. Wouldn't solve it for other non-jbi things.
2) Update SoapEndpoint.java to cast the ComponentContext to
AbstractComponentContext and grab the NMR directly and query it directly
bypassing the "jbi.internal" flag thing. Maybe just do it if the current
code fails to find an endpoint? That would fix it for the servicemix-soap
family of endpoints, but not anything else that may be looking up endpoints
via the ComponentContext.
3) Change the behavior of AbstractComponentContext somehow. Assume anything
without the "jbi.external" key set is internal and for an "internal" lookup,
return all the endpoints that don't have the external flag set. This
should fix it for everything, but it's definitely a bit more complex.
For 3, I'm thinking of getting rid of jbi.internal entirely. All
registrations through jbi would end up setting jbi.external to a real boolean
of TRUE or FALSE depending on if it's external or not.
When doing queries for internal, the property object would set the
jbi.external to an instance object like:
class IsInternal {
public boolean equals(Object obj) {
return Boolean.FALSE.equals(obj) || obj == null;
}
}
For jbi external endpoints, that would eval to false as the passed in obj
would be TRUE. For internal jbi endpoints, the obj would be FALSE and thus
the equals would return true. For non-jbi endpoints, it would be null and
return true as well.
Anyway, other ideas or thoughts?
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Problem with servicemix-http and non-jbi registered endpoints....
Posted by Gert Vanthienen <ge...@gmail.com>.
Hi Dan,
In my mind, adding a Wire to the WireRegistry would be a good quick
fix then. That way, we can have a JBI-compatible alias for the CXF
NMR endpoint without doing the hacky bit in option 1 (i.e. adding the
unnecessary property to the properties map)
Wdyt?
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On 22 July 2010 22:54, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>> By the way: what is the use case for exposing the NMR endpoint as a
>> JBI endpoint? Is the goal just to share the same endpoint between
>> both types of messaging or is there some feature in CXF-NMR that's
>> missing from the JBI CXF BC/SE components?
>>
>
> Well, the use case is Swordfish right now. For some reason, they are using
> the CXF-NMR stuff to wire CXF services into the NMR, but are using the
> servicemix-http component for the http level stuff. It really is a kind of
> bizarre setup and long term, changing to BC/SE is definitely the way to go,
> but I'm trying to fix some short term issues immediately.
>
> Customers getting in the way again.........
>
>
> Dan
>
>
>
> On Thursday 22 July 2010 4:39:58 pm Gert Vanthienen wrote:
>> L.S.,
>>
>> Up to now, I guess we never considered the use case of a JBI component
>> interacting with an NMR component. The way JBI and NMR messaging
>> semantics works, it should be possible to bridge both worlds. The
>> biggest difference is probably that the NMR is capable of conveying
>> non-XML payloads as well as XML payloads.
>>
>> It's probably not that useful to allow the JBI components to address
>> all the NMR endpoints, as some of them might not produce a suitable
>> XML result. E.g. I can imagine a CXF NMR endpoint to always reply
>> with a proper XML message, but a Camel NMR endpoint can send out about
>> anything. I don't think options 2 and 3 are really going to work if
>> we can't be sure that the NMR endpoint is even capable of handling the
>> message properly.
>>
>> Option 1 would probably work. We could also let NMR endpoints, that
>> are capable of handling JBI semantics directly, register a wire in the
>> WIreRegistry (which would be like an alias for the endpoint) to make
>> it available as a JBI endpoint as well.
>>
>> Another thing we could do build a little NMR bridge class we can add
>> to our Spring XML file to 'wrap' any kind of NMR endpoint and expose
>> it as a JBI endpoint. If we leverage the NMR's TypeConverter
>> mechanism, we can even handle other things like Camel NMR endpoint
>> that way.
>>
>> By the way: what is the use case for exposing the NMR endpoint as a
>> JBI endpoint? Is the goal just to share the same endpoint between
>> both types of messaging or is there some feature in CXF-NMR that's
>> missing from the JBI CXF BC/SE components?
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> Open Source SOA: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>> On 22 July 2010 03:23, Daniel Kulp <dk...@apache.org> wrote:
>> > I'm having a problem with the way servicemix-http interacts with
>> > endpoints that aren't registered through JBI. In particular, the
>> > cxf-nmr registered endpoints that register directly with the NMR.
>> >
>> > The issue I'm having is that when trying to load/create a WSDL, it's not
>> > finding the ServiceEndpoint to get the wsdl from. Digging into it, it
>> > seems to be an issue with AbstractComponentContext.
>> >
>> > When JBI based endpoints are registered, the ComponentContext adds an
>> > extra property to property map of either "jbi.internal" or
>> > "jbi.external" with a value of True. Endpoints not registered via
>> > JBI would not have those properties added.
>> >
>> > The problem is when servicemix-http queries, the AbstractComponentContext
>> > adds "jbi.internal"/True to the properties to match on automatically.
>> > Since the cxf-nmr Endpoint would not have added that property, the props
>> > don't match and no endpoint is returned. Thus, no wsdl. Thus, things
>> > like determining if an operation is one-way and such don't work.
>> >
>> > There are a couple ways to approach this and I'd like some advice from
>> > the "experts":
>> >
>> > 1) Have cxf-nmr add "jbi.internal" with it's properties. Kind of a
>> > hack job. Wouldn't solve it for other non-jbi things.
>> >
>> > 2) Update SoapEndpoint.java to cast the ComponentContext to
>> > AbstractComponentContext and grab the NMR directly and query it directly
>> > bypassing the "jbi.internal" flag thing. Maybe just do it if the
>> > current code fails to find an endpoint? That would fix it for the
>> > servicemix-soap family of endpoints, but not anything else that may be
>> > looking up endpoints via the ComponentContext.
>> >
>> > 3) Change the behavior of AbstractComponentContext somehow. Assume
>> > anything without the "jbi.external" key set is internal and for an
>> > "internal" lookup, return all the endpoints that don't have the external
>> > flag set. This should fix it for everything, but it's definitely a
>> > bit more complex.
>> >
>> > For 3, I'm thinking of getting rid of jbi.internal entirely. All
>> > registrations through jbi would end up setting jbi.external to a real
>> > boolean of TRUE or FALSE depending on if it's external or not.
>> >
>> > When doing queries for internal, the property object would set the
>> > jbi.external to an instance object like:
>> > class IsInternal {
>> > public boolean equals(Object obj) {
>> > return Boolean.FALSE.equals(obj) || obj == null;
>> > }
>> > }
>> >
>> > For jbi external endpoints, that would eval to false as the passed in obj
>> > would be TRUE. For internal jbi endpoints, the obj would be FALSE and
>> > thus the equals would return true. For non-jbi endpoints, it would be
>> > null and return true as well.
>> >
>> > Anyway, other ideas or thoughts?
>> >
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org
>> > http://dankulp.com/blog
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: Problem with servicemix-http and non-jbi registered endpoints....
Posted by Daniel Kulp <dk...@apache.org>.
>
> By the way: what is the use case for exposing the NMR endpoint as a
> JBI endpoint? Is the goal just to share the same endpoint between
> both types of messaging or is there some feature in CXF-NMR that's
> missing from the JBI CXF BC/SE components?
>
Well, the use case is Swordfish right now. For some reason, they are using
the CXF-NMR stuff to wire CXF services into the NMR, but are using the
servicemix-http component for the http level stuff. It really is a kind of
bizarre setup and long term, changing to BC/SE is definitely the way to go,
but I'm trying to fix some short term issues immediately.
Customers getting in the way again.........
Dan
On Thursday 22 July 2010 4:39:58 pm Gert Vanthienen wrote:
> L.S.,
>
> Up to now, I guess we never considered the use case of a JBI component
> interacting with an NMR component. The way JBI and NMR messaging
> semantics works, it should be possible to bridge both worlds. The
> biggest difference is probably that the NMR is capable of conveying
> non-XML payloads as well as XML payloads.
>
> It's probably not that useful to allow the JBI components to address
> all the NMR endpoints, as some of them might not produce a suitable
> XML result. E.g. I can imagine a CXF NMR endpoint to always reply
> with a proper XML message, but a Camel NMR endpoint can send out about
> anything. I don't think options 2 and 3 are really going to work if
> we can't be sure that the NMR endpoint is even capable of handling the
> message properly.
>
> Option 1 would probably work. We could also let NMR endpoints, that
> are capable of handling JBI semantics directly, register a wire in the
> WIreRegistry (which would be like an alias for the endpoint) to make
> it available as a JBI endpoint as well.
>
> Another thing we could do build a little NMR bridge class we can add
> to our Spring XML file to 'wrap' any kind of NMR endpoint and expose
> it as a JBI endpoint. If we leverage the NMR's TypeConverter
> mechanism, we can even handle other things like Camel NMR endpoint
> that way.
>
> By the way: what is the use case for exposing the NMR endpoint as a
> JBI endpoint? Is the goal just to share the same endpoint between
> both types of messaging or is there some feature in CXF-NMR that's
> missing from the JBI CXF BC/SE components?
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> Open Source SOA: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
> On 22 July 2010 03:23, Daniel Kulp <dk...@apache.org> wrote:
> > I'm having a problem with the way servicemix-http interacts with
> > endpoints that aren't registered through JBI. In particular, the
> > cxf-nmr registered endpoints that register directly with the NMR.
> >
> > The issue I'm having is that when trying to load/create a WSDL, it's not
> > finding the ServiceEndpoint to get the wsdl from. Digging into it, it
> > seems to be an issue with AbstractComponentContext.
> >
> > When JBI based endpoints are registered, the ComponentContext adds an
> > extra property to property map of either "jbi.internal" or
> > "jbi.external" with a value of True. Endpoints not registered via
> > JBI would not have those properties added.
> >
> > The problem is when servicemix-http queries, the AbstractComponentContext
> > adds "jbi.internal"/True to the properties to match on automatically.
> > Since the cxf-nmr Endpoint would not have added that property, the props
> > don't match and no endpoint is returned. Thus, no wsdl. Thus, things
> > like determining if an operation is one-way and such don't work.
> >
> > There are a couple ways to approach this and I'd like some advice from
> > the "experts":
> >
> > 1) Have cxf-nmr add "jbi.internal" with it's properties. Kind of a
> > hack job. Wouldn't solve it for other non-jbi things.
> >
> > 2) Update SoapEndpoint.java to cast the ComponentContext to
> > AbstractComponentContext and grab the NMR directly and query it directly
> > bypassing the "jbi.internal" flag thing. Maybe just do it if the
> > current code fails to find an endpoint? That would fix it for the
> > servicemix-soap family of endpoints, but not anything else that may be
> > looking up endpoints via the ComponentContext.
> >
> > 3) Change the behavior of AbstractComponentContext somehow. Assume
> > anything without the "jbi.external" key set is internal and for an
> > "internal" lookup, return all the endpoints that don't have the external
> > flag set. This should fix it for everything, but it's definitely a
> > bit more complex.
> >
> > For 3, I'm thinking of getting rid of jbi.internal entirely. All
> > registrations through jbi would end up setting jbi.external to a real
> > boolean of TRUE or FALSE depending on if it's external or not.
> >
> > When doing queries for internal, the property object would set the
> > jbi.external to an instance object like:
> > class IsInternal {
> > public boolean equals(Object obj) {
> > return Boolean.FALSE.equals(obj) || obj == null;
> > }
> > }
> >
> > For jbi external endpoints, that would eval to false as the passed in obj
> > would be TRUE. For internal jbi endpoints, the obj would be FALSE and
> > thus the equals would return true. For non-jbi endpoints, it would be
> > null and return true as well.
> >
> > Anyway, other ideas or thoughts?
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Problem with servicemix-http and non-jbi registered endpoints....
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
Up to now, I guess we never considered the use case of a JBI component
interacting with an NMR component. The way JBI and NMR messaging
semantics works, it should be possible to bridge both worlds. The
biggest difference is probably that the NMR is capable of conveying
non-XML payloads as well as XML payloads.
It's probably not that useful to allow the JBI components to address
all the NMR endpoints, as some of them might not produce a suitable
XML result. E.g. I can imagine a CXF NMR endpoint to always reply
with a proper XML message, but a Camel NMR endpoint can send out about
anything. I don't think options 2 and 3 are really going to work if
we can't be sure that the NMR endpoint is even capable of handling the
message properly.
Option 1 would probably work. We could also let NMR endpoints, that
are capable of handling JBI semantics directly, register a wire in the
WIreRegistry (which would be like an alias for the endpoint) to make
it available as a JBI endpoint as well.
Another thing we could do build a little NMR bridge class we can add
to our Spring XML file to 'wrap' any kind of NMR endpoint and expose
it as a JBI endpoint. If we leverage the NMR's TypeConverter
mechanism, we can even handle other things like Camel NMR endpoint
that way.
By the way: what is the use case for exposing the NMR endpoint as a
JBI endpoint? Is the goal just to share the same endpoint between
both types of messaging or is there some feature in CXF-NMR that's
missing from the JBI CXF BC/SE components?
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On 22 July 2010 03:23, Daniel Kulp <dk...@apache.org> wrote:
>
> I'm having a problem with the way servicemix-http interacts with endpoints
> that aren't registered through JBI. In particular, the cxf-nmr registered
> endpoints that register directly with the NMR.
>
> The issue I'm having is that when trying to load/create a WSDL, it's not
> finding the ServiceEndpoint to get the wsdl from. Digging into it, it seems
> to be an issue with AbstractComponentContext.
>
> When JBI based endpoints are registered, the ComponentContext adds an extra
> property to property map of either "jbi.internal" or "jbi.external" with a
> value of True. Endpoints not registered via JBI would not have those
> properties added.
>
> The problem is when servicemix-http queries, the AbstractComponentContext adds
> "jbi.internal"/True to the properties to match on automatically. Since the
> cxf-nmr Endpoint would not have added that property, the props don't match and
> no endpoint is returned. Thus, no wsdl. Thus, things like determining if
> an operation is one-way and such don't work.
>
> There are a couple ways to approach this and I'd like some advice from the
> "experts":
>
> 1) Have cxf-nmr add "jbi.internal" with it's properties. Kind of a hack
> job. Wouldn't solve it for other non-jbi things.
>
> 2) Update SoapEndpoint.java to cast the ComponentContext to
> AbstractComponentContext and grab the NMR directly and query it directly
> bypassing the "jbi.internal" flag thing. Maybe just do it if the current
> code fails to find an endpoint? That would fix it for the servicemix-soap
> family of endpoints, but not anything else that may be looking up endpoints
> via the ComponentContext.
>
> 3) Change the behavior of AbstractComponentContext somehow. Assume anything
> without the "jbi.external" key set is internal and for an "internal" lookup,
> return all the endpoints that don't have the external flag set. This
> should fix it for everything, but it's definitely a bit more complex.
>
> For 3, I'm thinking of getting rid of jbi.internal entirely. All
> registrations through jbi would end up setting jbi.external to a real boolean
> of TRUE or FALSE depending on if it's external or not.
>
> When doing queries for internal, the property object would set the
> jbi.external to an instance object like:
> class IsInternal {
> public boolean equals(Object obj) {
> return Boolean.FALSE.equals(obj) || obj == null;
> }
> }
>
> For jbi external endpoints, that would eval to false as the passed in obj
> would be TRUE. For internal jbi endpoints, the obj would be FALSE and thus
> the equals would return true. For non-jbi endpoints, it would be null and
> return true as well.
>
> Anyway, other ideas or thoughts?
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>