The namespace handler support in the blueprint RFC specified to use
DOM before it was pulled from the 4.2 spec, which is why DOM is used
here.
The OSGi Alliance is looking at namespace handlers again, I don't have
a problem with something more modern being used, but I am worried
about changing if the standard ends up using DOM.
Alasdair
On 6 Jan 2010, at 19:15, The Dweller <[email protected]> wrote:
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
