cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Attempting to remove wsdl4j dependency from the JAX-RS frontend
Date Thu, 18 Nov 2010 20:02:23 GMT
On Thursday 18 November 2010 2:38:19 pm Sergey Beryozkin wrote:
> Hi
> After making an initial attempt to resolve CXF-3021 [1] and limiting the
> WSDLEndpointFactory update to 2.4.0 only, as agreed on IRC, I realized
> today the problem was much more involved. See the comments at the JIRA.
> I've spend a lot of time today trying to close this issue but it proved to
> be tricky. Overall I'm mostly happy with the patch and I feel this kind of
> refactoring is a positive step.
> The bit I'm not quite comfortable with is the changes in the HTTP transport
> where I end up catching NoClassDefFoundError in cases when WSDL4J-'backed'
> classes such as HttpServerPolicy and Address CXF extensions are loaded.

I personally think it would be better to add a utility method like "boolean 
isWSDL4JAvail()" someplace and call that prior to using any code that requires 
it instead of dealing with the NoClassDefFound things.   Seems a bit cleaner 
to me.

> I
> think they are actually safe, as it is kind of unlikely that these
> extensions are expected to be available in non-WSDL first cases and in WSDL
> first cases wsdl4J will be there anyway. And if say people want to use
> HttpServerPolicy explicitly in java-first cases then they'd obviously have
> to have wsdl4j available. I wish I could come up with a cleaner approach.
> Comments are welcome. If we can not make the patch it 'merge-able' then I'd
> have to revert the WSDLEndpointFactory change too as it would be pointless;
> I hope we can sort it out though somehow :-)

Does the  servlets services list use the correct URL's without the AddressType 
thing avail?    Something to double check.


> cheers, Sergey
> [1]

Daniel Kulp

View raw message