cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <asold...@redhat.com>
Subject Re: Another 3.0 thought….
Date Sat, 18 May 2013 08:35:59 GMT
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

Mime
View raw message