Re: Remnant Xerces Dependency?

Ok, here's the official statement from the Xerces developers...

<quote>
 > But the question still remains, if it 
[org.w3c.dom.html.HTMLDOMImplementation] isn't in xml-apis.jar because it isn't
 > a "standard
 > interface for HTML DOM Level 1", then why is it in xercesImpl.jar?

Xerces2 ships this interface to preserve backwards compatibility with
the previous releases.

Thank you,
-- 
Elena Litani / IBM Toronto
</quote>

So, basically,  it was pretty much dumb luck that HTMLDOMImplementation 
even exists in Xerces2 at all.  Well, I suppose it could be said that if it 
wasn't there, I would have realized it way back when (although it ships 
with j2sdk1.4.x, so it is debatable whether I'd have discovered the missing 
class) and XMLC-2.2 would have shipped with this class in its own jar.

Anyway, it might not be a bad idea, for the time being, to add 
org.w3c.dom.html.HTMLDOMImplementation to XMLC's own jar (or maybe the 
xerces.jar which would, by proxy, be included in the 
xmlc-all-runtime.jar).  How does that sound?  Richard, David, Mark, anyone 
else?  The one problem I can think of is that this would be an endorsed 
package and containers like Tomcat-4.1.x and above will refused to load 
this class from the WebappClassLoader.  Essentially, it has to be in a 
parent class loader such as in Tomcat where xmlParserAPIs.jar (same as 
xml-apis.jar) and xercesImpl.jar are in 
CATALINA_HOME/common/endorsed.  Hmmmm..... we might have to simply live 
with this dependency because the proposed cure might be worse than the 
disease (class loader confusion experienced by users) :-(

Jake

At 09:54 AM 9/3/2003 -0500, you wrote:

>Oh, I see.  I didn't even realize that.  That seems like a packaging 
>problem on the part of Xerces2.  There isn't any reason I can think of 
>that HTMLDOMImplementation should exist in xercesImpl.jar?  I'll ping the 
>Xerces2 list to see what they have to say.
>
>thanks for reporting that and making the clarification.
>
>....ok, hold on.  I see why it is packaged that 
>way.  HTMLDOMImplementation is part of DOM Level2 where the HTML DOM that 
>Xerces includes is part of DOM Level 1.  However, this is a bit 
>inconsistent because HTML DOM Level2 is in the org.w3c.dom.html2 package 
>where they are distributing the HTMLDOMImplementation under the original 
>Level1 package.  Seems to me that it is legitimate to have the 
>experimental DOM Level3 Load/Save package under XercesImpl.jar, but the 
>HTMLDOMImplementation really should be distributed with the xml-apis.jar.
>
>The reason for all this confusion is that Xerces-1.4.4 uses an unofficial 
>version of the HTML DOM Level2 apis which included 
>HTMLDOMImplementation.  This was before they changed the package name to 
>org.w3c.dom.html2.  This was not legitimate since Xerces doesn't even 
>support HTML DOM Level2 features.  Only Level1 is officially 
>supported.  When I removed the incorrect api's in favor of the ones that 
>come with Xerces2, there were actually a couple places that depended on 
>the Level2 methods that I had to correct in XMLC.  If this packaging issue 
>is fixed, then we should not have any more issues with a xercesImpl.jar 
>dependency.
>
>Jake
>
>At 07:35 AM 9/3/2003 -0500, you wrote:
>>I don't mind having this dependency in place, but just to clarify, I 
>>already was
>>including xml-apis.jar.  I had to add xercesImpl.jar (which I downloaded
>>separately from the Xerces site) because it includes
>>org/w3c/dom/html/HTMLDOMImplementation, while xml-apis.jar does not.
>>
>>Regards,
>>
>>Aaron
>>---
>>Aaron Kardell
>>Development Manager & Chief Architect of SIPS
>>Altona Ed, LLC <http://www.altonaed.com/>
>>[email protected]
>>
>>
>>
>>Quoting [email protected]:
>>
>> > Date: Tue, 02 Sep 2003 22:03:49 -0500
>> > To: [email protected]
>> > From: Jacob Kjome <[email protected]>
>> > Subject: Re: Xmlc:  Remnant Xerces Dependency?
>> > Reply-To: [email protected]
>> >
>> >
>> > Actually, this isn't a bug.  I removed the w3c standard interfaces 
>> from the
>> > CVS source of Xerces-1.4.4.  Notice that xml-apis.jar is distributed with
>> > xmlc-2.2 in build-lib.  I guess the bug is that I didn't mention this is
>> > the release notes.  Here's the deal...
>> >
>> > Internally, XMLC will use its own implementation of the standard 
>> interfaces
>> > (xerces-1.4.4).  If you create nodes and such outside of XMLC, you will
>> > need both the standard interfaces + some dom implementation such as
>> > Xerces2, Xerces1, or Crimson (haven't tested with Crimson, though).
>> >
>> > It might look at bit odd that XMLC, internally, uses Xerces-1.4.4, but
>> > requires you to use another dom implementation external to this, but you
>> > need to weigh that with the fact that XMLC no longer limits you to its own
>> > dom implementation (xerces-1.4.4 modified).  In the future, this will be
>> > remedied and there won't be this kind of duplication, but it was the
>> > simplest way to fix colliding dom implementations (since Xerces2 is now
>> > used so commonly in many container environments).
>> >
>> > So, yes, XMLC does require xml-apis.jar (comes with Xerces-2.5) to be in
>> > the classpath and the dom implementation of your choice (probably
>> > Xerces2).  Sorry for not being clear about this in the release notes.
>> >
>> > Jake
>> >
>> > At 08:16 PM 9/2/2003 -0500, you wrote:
>> > >Greetings,
>> > >
>> > >I've been using XMLC 2.2 in production since its release, and I must 
>> say --
>> > >great job!  However, I have uncovered a minor bug -- it appears there 
>> is a
>> > >remnant Xerces dependency, as adding xercesImpl.jar to the classpath 
>> fixes
>> > the
>> > >problem.  Here is the stack trace:
>> > >
>> > >java.lang.NoClassDefFoundError: org/w3c/dom/html/HTMLDOMImplementation
>> > >         at java.lang.ClassLoader.defineClass0(Native Method)
>> > >         at java.lang.ClassLoader.defineClass(ClassLoader.java:488)
>> > >         at
>> > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:106)
>> > >         at java.net.URLClassLoader.defineClass(URLClassLoader.java:243)
>> > >         at java.net.URLClassLoader.access$100(URLClassLoader.java:51)
>> > >         at java.net.URLClassLoader$1.run(URLClassLoader.java:190)
>> > >         at java.security.AccessController.doPrivileged(Native Method)
>> > >         at java.net.URLClassLoader.findClass(URLClassLoader.java:183)
>> > >         at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
>> > >         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281)
>> > >         at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
>> > >         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310)
>> > >         at
>> >
>> >org.enhydra.xml.lazydom.html.LazyHTMLDocument.getImplementation(LazyHTML 
>> D ocument.java:198)
>> > >         at
>> >
>> >org.enhydra.apache.xerces.dom.CoreDocumentImpl.importNode(CoreDocumentIm 
>> p l.java:901)
>> > >         at
>> >
>> >org.enhydra.apache.xerces.dom.CoreDocumentImpl.importNode(CoreDocumentIm 
>> p l.java:862)
>> > >
>> > >This occurs when attempting to make the following call:
>> > >
>> > >contentArea.appendChild(contentArea.getOwnerDocument().importNode(main 
>> N ode,
>> >
>> > >true));
>> > >
>> > >where both contentArea and mainNode are Elements taken directly from XMLC
>> > >generated templates.
>> > >
>> > >Let me know if you have any questions -- I'll be happy to help to help
>> > >debug/pinpoint this problem.
>> > >
>> > >Regards,
>> > >
>> > >Aaron
>> > >---
>> > >Aaron Kardell
>> > >Development Manager & Chief Architect of SIPS
>> > >Altona Ed, LLC <http://www.altonaed.com/>
>> > >[email protected]
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >_______________________________________________
>> > >XMLC mailing list
>> > >[email protected]
>> > >http://www.enhydra.org/mailman/listinfo.cgi/xmlc
>> >
>> >
>> >
>> > --__--__--
>> >
>> > _______________________________________________
>> > XMLC mailing list
>> > [email protected]
>> > http://www.enhydra.org/mailman/listinfo.cgi/xmlc
>> >
>> >
>> > End of XMLC Digest
>> >
>>
>>_______________________________________________
>>XMLC mailing list
>>[email protected]
>>http://www.enhydra.org/mailman/listinfo.cgi/xmlc
>
>_______________________________________________
>XMLC mailing list
>[email protected]
>http://www.enhydra.org/mailman/listinfo.cgi/xmlc