actually the quick fix is to ignore the "useHttps" in here. If the value of
ENDPOINT_ADDRESS_PROPERTY starts with https, I set the value of useHttps to
true, false otherwise. It seems to work just fine in my production
environment now.
if (useHttps
|| configuredConduit.getTlsClientParameters() != null) {
TLSClientParameters params = configuredConduit.getTlsClientParameters();
On Fri, Jan 9, 2009 at 12:55 AM, Glen Mazza <[email protected]> wrote:
>
> 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.
>
>
