Hi Dan,
I agree with you and will commit a patch with your suggestion shortly.
Willem
On 9/15/10 9:23 AM, Daniel Kulp wrote:
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
