cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <glen.ma...@gmail.com>
Subject Re: problem changing endpoint address from https to http
Date Thu, 08 Jan 2009 16:55:07 GMT

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
> dkulp@apache.org
> 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.


Mime
View raw message