JAX-WS doc

[Benson Margulies <bi...@gmail.com>]

The main JAX-WS page should link to
http://cxf.apache.org/docs/a-simple-jax-ws-service.html. I can fix
that. The simple page should be really clear on the role of CXF
extensions (null WSDL, ASM code generation). I'm not entirely clear on
the later.

Re: JAX-WS doc

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

On Monday 11 October 2010 7:48:25 am Benson Margulies wrote:
> The main JAX-WS page should link to
> http://cxf.apache.org/docs/a-simple-jax-ws-service.html. I can fix
> that. The simple page should be really clear on the role of CXF
> extensions (null WSDL, ASM code generation). I'm not entirely clear on
> the later.

If you figure out a good place to put the ASM info, point me at it.   :-)

Seriously, there are TWO areas where ASM is used:

1) To create higher performance helpers to work with the wrapper types.   
Without ASM, we have a Reflection based helper that is used to pull 
information out of the wrapper types and to create a wrapper object based on 
the parms/returns.   For larger wrapper objects and such, the reflection 
methog overhead can add up a bit.    If ASM is available, we generate a helper 
class that calls the get/set methods directly and avoids reflection (except 
for the first hit when the class is generated).     In this case, ASM is 
completely optional, it just provides a slight performance boost.  (but not 
really a big one considering a majority of the time is spent in the XML 
parsing and JAXB processing and such)

2) Generating Wrapper types.   When using the JAX-WS frontend (doesn't apply  
to simple frontend, yet) if the SEI/Class does not have 
@Request/ResponseWrapper annotations or if the wrapper annotations don't point 
to loadable classes, we use ASM to generate in memory wrapper classes.  If ASM 
is not available, we CAN try and write/read each param/return individually, 
but there are some limitations with that approach.
   a)  Performance - JAXB requires a little bit of setup and such each time 
it's invoked.  With a wrapper class, that is done once instead of for each 
param/return.

   b) (a) get's worse with Lists/arrays.   Since JAXB/JAX-WS flattens them to 
a element with minOccurs=unbounded, we have to call into JAXB for each element 
in the collection.   

   c) Some things are not supportable at all or only via the use of non-
standard JAXB-API calls.   For example, if you use an @XmlList annotation on a 
param, we either have to have a wrapper object for it or we have to use the 
Sun-RI "Bridge" classes to have that annotation honored.  Using the Bridge 
stuff then means alternative JAXB implementations are not usable (like Eclipse 
Moxy).



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