Blueprint NamespaceHandlers: DOM or Stax?

[David Jencks <da...@yahoo.com>]

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

Re: Blueprint NamespaceHandlers: DOM or Stax?

[Alasdair Nottingham <no...@apache.org>]

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 <ba...@gmail.com> 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  
> <da...@yahoo.com> 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
>>
>>

Re: Blueprint NamespaceHandlers: DOM or Stax?

[The Dweller <ba...@gmail.com>]

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 <da...@yahoo.com> 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
>
>