I don't have a strong view on this, but the reasons for not allowing protocol switches via ENDPOINT_ADDRESS_PROPERTY may indeed be legitimate, both from an internal CXF architecture and an end-user perspective. From an internal perspective, CXF's bus may already be fully configured for a particular protocol by the time a protocol change request via ENDPOINT_ADDRESS_PROPERTY is made, so that might require risky duplication of business logic to switch CXF to the other protocol (as what you're saying with JMS), also a chance of the business logic in two different places falling out of sync. That wouldn't be good for anyone.
>From the end-user perspective, there is always the chance the switch from https:// to http:// or vice-versa was inadvertent, and a CXF that happily hums along without complaint might end up harming more people than it helps. So as long as the JAX-WS spec does not mandate protocol switch support via that statement, the occasional user grumbling over needing to use Ant's XSLT task to fix his one hundred WSDLs all at once (and, yes, it can process an endless number of WSDLs in a given directory with a single XSLT all at once) could be a price worth paying. Glen dkulp wrote: > > On Tuesday 06 January 2009 6:06:01 pm Glen Mazza wrote: >> If CXF is ignoring BindingProvider.ENDPOINT_ADDRESS_PROPERTY, then yes, >> that's a bug. Please submit a JIRA for it. > > CXF isn't "ignoreing" the ENDPOINT_ADDRESS_PROPERTY. However, CXF > doesn't > allow changing protocols via the ENDPOINT_ADDRESS_PROPERTY. You cannot > change from HTTP -> JMS for example via setting that property. Right now, > CXF considers a change from HTTP -> HTTPS (and vice versa) a protocol > change. > > Fixing the HTTP -> JMS thing would be quite a bit of work as that involves > an > interceptor very early in the chain that would completely swap out the > conduit. Fixing http <---> https is a quit bit easier, in a > semi-hackish > way. Testing a fix now. If the ENDPOINT_ADDRESS_PROPERTY is set, I can > just wipe out the connectionFactory and re-acquire it. Not ideal, but a > temporary fix. > > > Dan > >> >> Glen >> >> Christopher Cheng wrote: >> > It's probably a bug in version 2.1.3 >> > >> > <snip/> >> > >> > The following is from HTTPConduit. If defaultEndpointURL is not null, >> it >> > will not use the new URL in BindingProvider.ENDPOINT_ADDRESS_PROPERTY. >> > Therefore, the only way is to change defaultEndpointURL in WSDL which >> is >> > not >> > user friendly. Could this be improved in version 2.1.4? > > > > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog > > -- View this message in context: http://www.nabble.com/Re%3A-Re%3A-problem-changing-endpoint-address-from-https-to-http-tp21254391p21355782.html Sent from the cxf-user mailing list archive at Nabble.com.
