Attempting to remove wsdl4j dependency from the JAX-RS frontend

[Sergey Beryozkin <sb...@gmail.com>]

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
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 :-)

cheers, Sergey

[1] https://issues.apache.org/jira/browse/CXF-3021

Re: Attempting to remove wsdl4j dependency from the JAX-RS frontend

[Daniel Kulp <dk...@apache.org>]

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.

Dan


> 
> cheers, Sergey
> 
> [1] https://issues.apache.org/jira/browse/CXF-3021

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog