Another 3.0 thought….

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

This is something I'm still noodling on, but thought I'd start a discussion about it.

Currently, wsdl2java will generate 100% JAX-WS compatible code.  No cxf isms in the code at all.  Default is JAXWS 2.2, but there is a jaxws21 flag for the older version.   That's all fine.  However, that does make using the code with CXF a little harder and more "magic" has to happen under the covers.   This is also why we get stack traces that point into the JAX-WS impl in the JDK, etc…

I'd like to change the generated "*Service" class to do a few things:

1) Instead of extending javax.xml.ws.Service, have it extend a class in CXF (that may then extend Service) that would directly instantiate the CXF related classes to avoid the SPI discovery stuff.

2) Add constructors/setters for things like Bus, CXF Features, etc…


The generated interfaces could be exactly the same.  It would pretty much be a drop in replacement as code like:

FooService service = new FooService();
FooPort port = service.getFooPort();

would work exactly the same.   It would just allow us to have a way to set/configure things easier than through magic "default bus" and thread locals and casting and such.  Thus, you could do things like:

FooService service = new FooService(bus);
FooPort port = service.getFooPort(new LoggingFeature(), new GZipFeature());

We would still have the -jaxws and -jaxws21 flags on wsdl2java which would keep things exactly as they are now.   We'd just add a new "frontend" to the code generator for this.


Actually, that brings up another idea:
Features in CXF were originally only subclasses of "AbstractFeature" as we didn't want to tie things to jaxws API since that was not built into the JDK.  Now that JAXWS api is built into all the versions of the JDK we support, we could make AbstractFeature extend WebServiceFeature and update the code that deals with WebServiceFeature to do "instanceof" on them and handle them appropriately.


Thoughts?

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: Another 3.0 thought….

[Alessio Soldano <as...@redhat.com>]

Hi Dan,
as long as the classes returned extend the JAXWS spec one, I think it
should be fine. And I assume standard methods should keep on working the
same as today. So we'd basically end up providing additional methods in
e.g. service to allow explicitly setting Bus, features and so on for
those users who already know they're needing more then plain jaxws.
Quite handy.
This said, I believe it should be possible to go on achieving the same
the current way (default bus etc). For example, from a JBossWS
integration point of view, there's definitely value in being able to
tune CXF behaviour while exposing pure JAXWS code to the user.

WRT making the AbstractFeature extend the WebServiceFeature, I fully agree.

On 05/17/2013 07:51 PM, Daniel Kulp wrote:
> 
> This is something I'm still noodling on, but thought I'd start a discussion about it.
> 
> Currently, wsdl2java will generate 100% JAX-WS compatible code.  No cxf isms in the code at all.  Default is JAXWS 2.2, but there is a jaxws21 flag for the older version.   That's all fine.  However, that does make using the code with CXF a little harder and more "magic" has to happen under the covers.   This is also why we get stack traces that point into the JAX-WS impl in the JDK, etc…
> 
> I'd like to change the generated "*Service" class to do a few things:
> 
> 1) Instead of extending javax.xml.ws.Service, have it extend a class in CXF (that may then extend Service) that would directly instantiate the CXF related classes to avoid the SPI discovery stuff.
> 
> 2) Add constructors/setters for things like Bus, CXF Features, etc…
> 
> 
> The generated interfaces could be exactly the same.  It would pretty much be a drop in replacement as code like:
> 
> FooService service = new FooService();
> FooPort port = service.getFooPort();
> 
> would work exactly the same.   It would just allow us to have a way to set/configure things easier than through magic "default bus" and thread locals and casting and such.  Thus, you could do things like:
> 
> FooService service = new FooService(bus);
> FooPort port = service.getFooPort(new LoggingFeature(), new GZipFeature());
> 
> We would still have the -jaxws and -jaxws21 flags on wsdl2java which would keep things exactly as they are now.   We'd just add a new "frontend" to the code generator for this.
> 
> 
> Actually, that brings up another idea:
> Features in CXF were originally only subclasses of "AbstractFeature" as we didn't want to tie things to jaxws API since that was not built into the JDK.  Now that JAXWS api is built into all the versions of the JDK we support, we could make AbstractFeature extend WebServiceFeature and update the code that deals with WebServiceFeature to do "instanceof" on them and handle them appropriately.
> 
> 
> Thoughts?
> 


-- 
Alessio Soldano
Web Service Lead, JBoss