On Wed June 24 2009 1:24:02 pm Daniel Kulp wrote:
> On Wed June 24 2009 12:05:46 pm Andrew Clegg wrote:
> > > One thing I keep meaning to try getting to work is to allow
> > > Provider<XMLStreamReader> to get the raw XMLStreamReader that we use.
> > > That would provide the best performing and best memory usage scenario.
> > > It's just not working yet.
> >
> > That would be awesome. What are the major stumbling blocks? I'm
> > tempted to have a go myself, although if it's giving you serious
> > trouble, I'm not sure how much help I could be...
>
> The MAJOR stumbling block are all the subclasses of
> AbstractInDatabindingInterceptor. Basically, after they call the
> "datareader.read(...)" stuff, they advance the XMLStreamReader to the next
> element (or end element) to see if there is "more stuff" that needs to be
> read and then throw an exception if too much stuff is there. It
> basically assumes the databinding has "consumed" the data for the current
> element so it can do that. That won't work in this case as the databinding
> wouldn't have actually done anything with the stream.
>
> Thus, some flag needs to be added in to forcefully say "there is only one
> thing to read, don't do anything after it" to those interceptors.
> Nothing major, just define the flag and look for it. (like
> msg.getContextualProperty("read.single.part") or similar).
Actually, another option could be to forget the flag and just check the return
of datareader.read(....) and if the return is = to the reader passed in, then
auto skip. Probably a lot simpler.
Dan
>
> Beyond that, it's just simple additions to the Readers/Writers in the
> "source" databinding. Nothing major at all there.
>
>
> As always, a patch would be awesome!
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
