On Tuesday 14 September 2010 8:58:27 pm Willem Jiang wrote:
> Hi Dan
>
> On 9/14/10 11:06 PM, Daniel Kulp wrote:
> > On Tuesday 14 September 2010 8:47:34 am Willem Jiang wrote:
> >> On 9/14/10 4:16 PM, Willem Jiang wrote:
> >> After checking the change log and the chat log, I found why we have the
> >> upper codes. The upper codes is try to support to specify the address
> >> with JMS URI in code first model with JAXWS API (You can't specify the
> >> transportId from that). But it will cause the side effect that CXF 2.3.0
> >> will not support the old JMS configuration out of box.
> >>
> >> As we can't get the address string from the SoapBindingConfiguration to
> >> workaround this issue, JAXWS API doesn't support the SOAP over JMS
> >> specification out of box, and we still support the old JMS
> >> configuration, so I suggest to remove this code.
> >
> > No, we really want a jaxws style Endpoint.publish("jms://.....") type
> > thing to work with the soap/jms stuff.
> >
> > One option would be to have an extra flag on SoapBindingInfo that record
> > if this is really a full "soap/jms spec compliant" thing or not. The
> > SoapBindingFactory could then use that flag to determine whether to add
> > the extra interceptors or not.
> >
> > Would that work?
> >
> > Dan
>
> The address is bond to endpoint which is decoupled with the BingingInfo,
> so it is hard to detect the address information when we create the
> SoapBindingInfo.
>
> Here is a way to override the transportId without any addition
> configuration for the jaxws style Endpoint.publish("jms://....."). As
> the old JMS transport doesn't support the jms URI,
Umm.. Yes it does. There is only one JMS transport and it does support the
JMS URL (as well as the old config). You can set the binding type to the XML
binding and use a JMS URL and that should also work (XML over JMS).
The SOAP transport is the problem here. When the SOAP transport is used, if
it detects the old JMS transport ID (detected from the jms:// URL), it
switches it to the new ID and then adds some interceptors that are now
incompatible. That's what needs to be turned off. I believe it can switch
the ID, but it cannot add the interceptor.
How about this (should cover 95% of the usecase): if the URL is JUST jms://
and nothing else, it doesn't flip the ID. If there is anything beyond the
jms://, assume it's the new style URL and flip. Since the new style requires
SOMETHING beyond there, that should work. None of our old examples ever used
anything other than jms:// for the address for old style stuff.
WYT?
Dan
> we just need to hack
> the transportId looking up processor from the
> AbstractWSDLBasedEndpointFactory to set the transportId with soap over
> jms transportId if there is an address which is started with "jms://".
>
> How about it?
>
> Willem
>
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
