The quick answer is the blueprint parser is using DOM, so ns handlers being part of that process also use the same api.
If the bp parser were rewritten to use stax, then the ns handler interface would need updating also. Of course, then you'd have to consider if we'd want to maintain some sort of compatibility bridge to support the older ns handler dom based interface. As ns handlers are associated to their URIs, we could even multiple api impls for a given URI, and support a priority ordering for which we'd use.. What are peoples thoughts, moving the parser over wouldnt be trivial, but wouldnt be excessively large either.. maintaining support for the older ns handler interface would be a must in the short term at least.. and would certainly complicate things a little. Regards, Ozzy On Wed, Jan 6, 2010 at 6:59 PM, David Jencks <[email protected]> wrote: > I've been working on converting the xbean-spring namespace handler to work > with blueprint and really wonder why NamespaceHandler is specified to use > DOM rather than Stax. Is this an historical accident that should be > corrected ASAP or is there an actual benefit to using DOM? > > I haven't looked into the insides of aries blueprint, would it be a good > idea to use stax there also? > > thanks > david jencks > >
