Re: Remnant Xerces Dependency?

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(LazyHTMLDocument.java:198)
>         at
>org.enhydra.apache.xerces.dom.CoreDocumentImpl.importNode(CoreDocumentImpl.java:901)
>         at
>org.enhydra.apache.xerces.dom.CoreDocumentImpl.importNode(CoreDocumentImpl.java:862)
>
>This occurs when attempting to make the following call:
>
>contentArea.appendChild(contentArea.getOwnerDocument().importNode(mainNode, 
>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