Re: Moving XMLC to Xerces 2 won't help...

This is a very good point. We don't actually need Xerces2, we just need XMLC
to work with everything else. And with the automated refactoring tools
available, this should be an easy win.

+1 for David's solution.

Adam.


----- Original Message -----
From: "David Li" <david@xxxxxxxxxxxxxxxxx>
To: <xmlc@xxxxxxxxxxx>
Sent: Thursday, January 23, 2003 11:08 AM
Subject: Re: Xmlc: Moving XMLC to Xerces 2 won't help...


> >> So, what happens is that if one needs to use an older API, you
> >> force that API on everything running under that appserver since it has
> >> to be loaded in a parent ClassLoader where all apps see it.  For apps
> >> that require newer versions, this causes some bad collisions.
> >
> > Yes, this is generally an unsolved problem in java!
>
> And the introduction of endorsed API makes it even worse. On top of
> that, the endorsed directory behavior isn't as documented.
>
> >> Now, as far as DOM3 goes, how much DOM3 specific stuff is used in
> >> XMLC?  I wonder how big of an issue that is?
> >
> > I don't  think any; guys???
>
> Yes, Mark you are busted for using DOM Level 3 API. In the org.w3c.dom
> package in Xerces 1, many methods are DOM Level 3 and several of them
> are used. Richard has a patch using reflection to deal with the issues
> and there is a list of DOM Level 3 methods used.
>
> > Another problem is that the LazyDOM is a derived DOM, which makes it
> > implementation-dependent.
>
> I think we should just move the patched Xerces into the
> org.enhydra.xmlc name space. From the point of LazyDOM, I'd argue that
> it makes perfect senses to do so. LazyDOM depends not on interfaces but
> implementations of the particular Xerces it uses. We can not really
> move LazyDOM among different versions of Xerces 1 and expect it to just
> work.
>
> I think we should really separate out the issues to 3 part of Xerces:
>
> 1. Parser: DTD access
> 2. DOM: LazyDOM depending on it
> 3. W3C DOM API: DOM Level 3
>
> We could attach the second one by moving the Xerces DOM used by LazyDOM
> into a different name space. In the old days, when XML parser is
> novelty, it nice to be able to use XMLC and get a XML parser as a side
> benefit. However, the problems we are having right now is really too
> many Xerces around and the conflicts amount them are the problem.
>
> I think I found the shortest path to solve the problem of integrating
> XMLC into today's environment. Instead of trying to push XMLC to more
> standard base, we push the part of XMLC that's conflicts with the
> environment into XMLC's private name space. Instead of removing
> dependency on Xerces and move it toward JAXP based, we just push the
> Xerces XMLC depending on into XMLC's private space.
>
> XMLC probably uses DOM more extensive then any applications out there.
> The common API such as JAXP are taking a lowest common denominator
> approach to the API.
>
> Drawback of this? Adding 1 MB of xmlc-xerces.jar to the size of your
> web application. Would this really be a problem to anyone?
>
> >> So, the question is, is it possible to stick to the more generic JAXP
> >> and DOM2 API's (and our own internals) and still have a functional
> >> XMLC?
> >
> > No, although it might be possible to isolate it more; there were
> > certainly
> > some short-cut taken.
>
> As above, I don't think moving to JAXP is a solution.
>
> > My feeling is that a short-term approach of getting things ported
> > to the latest xerces and getting the bug-fixes submitted would at least
> > keep people going with xmlc.
>
> I think we really have to look at why we need to move to the latest
> Xerces. We need to step back and look at the reason why so many want
> XMLC to move to Xerces 2. The #1 reason is to not having to alter the
> environment to suit the usage of XMLC. Users want to be able to package
> up the XMLC in the war and deploy the app to the application server
> without worrying about the conflicts between XMLC and their
> environment. However, from the point of view of the developers, we need
> the features provided by the specific implementation of Xerces to make
> our life easier without having to work around the limitation of common
> API.
>
> I think moving XMLC to latest Xerces isn't a solution. Integrate the
> Xerces XMLC depending on into XMLC's private space and have XMLC play
> nicely with the environment is.
>
> David Li
>
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc