cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: JiBX Databinding: databinding interface methods
Date Thu, 22 Jul 2010 02:16:18 GMT
On Wednesday 21 July 2010 5:19:42 pm Dennis Sosnoski wrote:
> On 07/22/2010 06:42 AM, Daniel Kulp wrote:
> > ...
> > Well, no.  It's ONLY used for code generation.   Not used for runtime at
> > all. It's mostly for filling in things like the classname attribute of
> > @RequestWrapper as well as for the types for the params at code
> > generation time.
> > 
> > 
> > ..
> > Well, runtime is different story.   For the most part, yes.  However, if
> > the runtime DataBinding object implements the WrapperCapableDatabinding,
> > then it provides the WrapperHelper object that would be used to set/get
> > the params in/out of the wrapper object.    Thus, it can do whatever
> > mapping it needs to do.   For example, JAXB will look at the @XmlElement
> > annotations and such as well to map the names.
> The "types for the params at code generation time" mentioned in the
> first quote only applies if the interface is unwrapped, right?

Correct.   If the databinding doesn't support unwrapping at runtime, then it 
should just return null and the code generator would keep things wrapped.   

> And in
> that case I assume the runtime DataBinding object must implement
> WrapperCapableDatabinding, right? (Since otherwise I don't see how the
> unwrapping could be handled).

Well, yes and no.   It should implement it if possible.    If not, what 
happens at runtime is that the WrappedInInterceptor would strip off the 
wrapper element and it would try and call into the databinding to read each 
individual part directly.   In some cases, this can be a bit slower as the 
databinding needs to set things up and such for each part instead of for the 
entire payload at once.   

For example, the Aegis databinding doesn't implement it as it doesn't 
support/generate types for the wrappers.    Then again, there isn't a code 
generator for Aegis.   :-)

On a historical note: when doing java first wrapped doc/lit,  CXF 2.0.x didn't 
really support using ASM to generate in-memory wrapper objects.   Thus, it did 
each part individually like that.  (and actually, with 2.2, if asm isn't 
avail, it tries as well).   However, with JAX-WS 2.1 (and more so with 2.2), 
certain JAXB annotations are allowed on the jaxws methods/params so doing it 
part by part like that requires digging deap into JAXB implementation "bridge" 
classes to get it to work.   In some cases, that still doesn't work which is 
why with 2.2, asm is now not marked optional for jaxws.

> So if I understand this correctly the JiBX DataBindingProfile code would
> need to generate a class to support returning a WrapperHelper at runtime
> to actually implement the wrapped support (since the JiBX code
> generation details won't otherwise be available at runtime).

Or it would need to be able to read/write the individual parts themselves.   

Daniel Kulp

View raw message