axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: [Axis2] In searching for a place for DOM impl
Date Mon, 21 Nov 2005 03:01:11 GMT

I think we should hold our horse on the dom stuff? Right now
security.mar will need it and saaj will need it. So having a separate
module is absolutely fine.

dom2/dom3 is a tricky problem. If we make some dom3 classes available
in axis jar itself as is being done now, we will land up in nasty
situations for classloader problems. Since the current use case is the
security.mar, having this code in a separate optional jar that is
loaded by security.mar (and associated classloader) seems to be the
way to go, IMHO.


On 11/20/05, Sanjiva Weerawarana <> wrote:
> On Sun, 2005-11-20 at 22:47 +0600, Eran Chinthaka wrote:
> > Hi all,
> >
> > As you know Ruchith is doing an implementation of DOM on OM. We have a
> > small problem in keeping this implementation.
> >
> > (ns:module= maven module)
> >
> > It was in the XML module for some time, but later moved to SAAJ module
> > to resolve a problem with JDK 1.5. But I feel like the DOM impl do not
> > belong to neither XML module nor SAAJ module.
> > I think I don't need to explain why it doesn't belong to SAAJ module. If
> > we put that in SAAJ, it will create a cyclic dependecy as well. And for
> > XML module, I'd like to have it clean only with the current stuff. I
> > think DOM impl should not come *in to* that module.
> > So the option left is to have a new and separate module for DOM
> > implementation. Its better to settle with something as I know Ruchith is
> > having an unnecessary headache due to this.
> > What do you all think ? I like to DOM impl, a separate module, so that
> > people who need that can use it, whilst others can discard it.
> What Ruchith is implementing is an *OM* implementation which also
> supports the DOM APIs. As far as a majority of Axis2 is concerned, we'll
> be using it as an OM implementation. Its just the security code that
> needs it to be a DOM implementation as well.
> As an OM implementation, we have a clear place to put it in: the XML
> module. We already have 2 OM implementations in there- the LLOM and the
> TableOM.
> So, as yet another OM implementation IMO it belongs in the XML module.
> Why would you discriminate against this OM implementation by putting it
> somewhere else?
> Note that putting it somewhere else causes difficulty with tests for
> example as all the OM tests are in the OM module. The OM tests should be
> run against both (or all) OM implementations so that we know immediately
> if one of those tests fail for some reason.
> Sanjiva.

Davanum Srinivas :

View raw message