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

Hi David,

I mostly agree with your sentiments.  The biggest reason I would like
XMLC to be compatible with Xerces2 is for compatibility with modern
environment.  The biggest problem here is in app
servers.  If the Java classloading spec allowed overriding of endorsed
packages, this wouldn't be a problem.  For instance, in a webapp, if
Java allowed one to use ones own XML/DOM packages loaded via the
WebappClassLoader (WEB-INF/lib and WEB-INF/classes), we wouldn't be
talking about this issue much at all.  As it happens, this can cause
some difficult-to-debug issues.  I have already posted an email
including links to a number of Tomcat bug reports regarding this
issue to prove my point (might have been just to you and not the XMLC
list, but I also sent it to the barracuda list at barracudamvc.org).
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.

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 the
problem is simply limited to DOM3.  There are other places where we
use Xerces specific classes such as Xerces-specific DOM parsers and
whatnot.  In many cases, I think we can use more of the generic JAXP
API instead.  That would make things more generic since we wouldn't be
directly referencing any particular library's implementation classes.
If we ever need specific functionality, we can always write our own
internal class.  At such time that the spec provides an interface
which supports our needs, we can more easily migrate from our own
internal classes to the spec interfaces or spec implementation classes
(such as those being provided in DOM3 when it comes out).  If we
always stick to the standard interfaces (+ our own internals), we wouldn't 
necessarily have
to ship a specific version of Xerces (or whatever library we use)
along with XMLC.  We would publish info about packages that we've
found to be the least buggy and recommend those, but we wouldn't force anyone 
to use any
specific version of Xerces or other XML/DOM library.  We would just require the 
library to
support the minimum standard specifications that XMLC depends upon.

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?  
Alternatively,
how much effort would it be to move to DOM4J.  In that case, we
wouldn't be worrying about the DOM spec at all (or much less) and we
also wouldn't have to worry about Java endorsed packages.  We
might even gain some performance.

Take a look at the following series of articles:
http://www-106.ibm.com/developerworks/xml/library/x-injava/
http://www-106.ibm.com/developerworks/xml/library/x-injava2/


DOM4j's only downside is that you don't have a choice of
implementations...unless a bunch of DOM4j compatible libraries come
out (which is possible since it uses interfaces rather than JDOM which
is all implementation classes like JDOM).  We would also want some
reassurance that DOM4j will continue to be developed.  I think it
will.  JDOM is posed to become a Java standard extension library, but
I have my doubts.  The development is incredibly slow for such a high
profile project.

Anyway, any thoughts on that?

Jake


Wednesday, January 22, 2003, 1:03:38 PM, you wrote:

DL> Jake, thanks on the note on Xerces 2's DOM3 API. However, looking at 
DL> this prompt me to ask this question. Why do we want to move XMLC to 
DL> Xerces 2 and does moving to Xerces 2 really helps solving the problem 
DL> with

DL> However, the DOM Level 3 API used by is actually located at the 
DL> org.w3c.dom. Moving that to depend on the Xerces 2's experimental 
DL> packages will still causes the same problem we are having right now, 
DL> not as frequently but still a possibility.

DL> Let me try to state the problems we are encountering with the current 
DL> XMLC and the reason why there are so many call for upgrading to Xerces 
DL> 2.

DL> 1. The patched Xerces in XMLC conflicts with the Xerces bundled in the 
DL> system you are trying to integrate XMLC into. Example of this: Ant. 
DL> Typically, you see the following exception when you run XMLC with Ant 
DL> without deleting its default Xerces implementation.

DL> Caused by: java.lang.NoSuchFieldError: fEntityHandler
DL>     at 
DL> org.apache.xerces.readers.XCatalog$Parser.setBase(XCatalog.java:472)
DL>     at 
DL> org.apache.xerces.readers.XCatalog$Parser.<init>(XCatalog.java:450)
DL>     at org.apache.xerces.readers.XCatalog.loadCatalog(XCatalog.java:223)

DL> 2. The patched Xerces in XMLC conflicts with the W3C DOM API bundled in 
DL> the system you are trying to integrate XMLC into. Example of this, 
DL> Tomcat. You see something like certain methods not found on only of the 
DL> org.w3c.dom interface. This is cause by the use of Level 3 API in XMLC.

DL> Any other reason that call for upgrading XMLC to Xerces 2?

DL> I am going to argue here that implementing XMLC using the unstable API 
DL> in Xerces 2 such as org.apache.xerces.dom3  will eventually causes the 
DL> same problem when we are finally done with moving XMLC to Xerces 2. We 
DL> should have no problem with with second one. Since more and more system 
DL> bundling Xerces 2 instead of 1, we are going to see the first problem 
DL> more frequently if the Xerces 2 bundled has different version then the 
DL> one we develop XMLC with in the case of experimental API change.

DL> XMLC probably uses more of the DOM API then anything applications out 
DL> there, thus it depending heavily on the DOM API, thus, sensitive to the 
DL> API changes.

DL> I am going to argue here is that without complete spec out why we want 
DL> to move XMLC to Xerces 2 and evaluate a stable base to build XMLC, 
DL> moving to Xerces 2 for the sake of moving to Xerces 2 will bring XMLC 
DL> right back to where we are today. Still posting work around on this 
DL> mailing list on how to get XMLC to work with your favorite system X. In 
DL> this case, we will be posting delete the Xerces and use Xerces 2.x.

DL> I think before we even attempt to move XMLC to Xerces 2, we need to 
DL> figure the requirement for such request. Otherwise, just like I said, 
DL> we will back to where we are right now.

DL> I think first requirement for redesign of XMLC is Depending strictly on 
DL> DOM Level 2.

DL> David


DL> On Tuesday, Jan 21, 2003, at 04:54 Asia/Shanghai, Jacob Kjome wrote:

>> Hello Jacob,
>>
>> Sorry, I got a bit confused as I wrote the last message.
>>
>> org.apache.xerces.dom3 package does exist and org.w3c.dom3 won't ever
>> exist.  It will always be underneath the org.w3c.dom package.  Sorry,
>> I wasn't thinking.
>>
>> Anway, it is implemented, but since dom3 stuff like
>> org.w3c.dom.DOMImplementationSource don't yet exist in Xerces2, it
>> does look like they don't yet officially support it.
>>
>> Again, sorry for confusing the issue.
>>
>> Jake

DL> -----------------------------------------------------------------
DL> < ¨C¤Ñ³£ Yahoo!©_¼¯ >  www.yahoo.com.tw

DL> _______________________________________________
DL> XMLC mailing list
DL> XMLC@xxxxxxxxxxx
DL> http://www.enhydra.org/mailman/listinfo.cgi/xmlc



-- 
Best regards,
 Jacob                            mailto:hoju@xxxxxxxx