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 Wed, 11 Aug 2010 19:16:31 GMT
On Saturday 07 August 2010 3:41:15 am Dennis Sosnoski wrote:
> On 07/22/2010 02:16 PM, Daniel Kulp wrote:
> > On Wednesday 21 July 2010 5:19:42 pm Dennis Sosnoski wrote:
> > 
> > ...
> > 
> >> 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.
> So as long as the databinding code can efficiently process multiple
> child elements one-at-a-time it's feasible to skip generating classes
> for the wrapper elements and instead just generate the data model? Then
> the WrappedInInterceptor would create a DataReader<T> instance for each
> child element of the wrapper, and call one of the read() methods? 

Yep.  That's how Aegis works.

> So does the WrappedInInterceptor know which type of DataReader<T> to
> create for each child element type by calling (at code generation time)
> the DataBindingProfile String getType(QName qn, boolean element) method?

No.  It passes the MessagePartInfo object into the reader for the part.   From 
there, the Databinding can figure out whatever it needs to do.   If it needs 
to call getType, it can.  If it has other ways to handle it, great.

> It sounds like we could use either approach with JiBX - generate classes
> for the wrapper elements, and support the DataBindingProfile String
> getWrappedElementType(QName wrapperElement, QName item) method call to
> provide code-generation-time information about the child element
> components *and* also generate WrapperHelper classes to get data in and
> out of the wrappers, or only generate the actual data classes and let
> WrappedInInterceptor handle the details. Since generating the
> WrapperHelper classes adds a fair amount of complexity, I'm thinking the
> latter approach might be better.

If it works, then yea.

Daniel Kulp

View raw message