You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by bu...@apache.org on 2002/01/18 09:35:57 UTC

DO NOT REPLY [Bug 5912] - Sealing violation: SAX Parser conflicts

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5912>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5912

Sealing violation: SAX Parser conflicts

geirm@optonline.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED



------- Additional Comments From geirm@optonline.net  2002-01-18 00:35 -------
Velocity itself doesn't need any XML support, so the core engine isn't 
causing your problem.  Anakia does indeed require XML support, and 
uses JDOM + werken.xpath to do that.

However, if you aren't using Anakia explicitly, you should be able to pull 
any and all XML-ish stuff (including werken.xpath, xalan, xerces) out of the 
classpath.

I am assuming that it's not classpath per se, but you have dumped the 
stuff from build/lib into WEB-INF/lib of your webapp?

Without really knowing what you are doing, I would null your CLASSPATH, 
put only necessary things plus Velocity's jar in WEB-INF/lib (use the jar-
dep target to make a Velocity jar that includes the dependencies like logkit 
and commons-collections to avoid that hassle - the jar will be velocity-
deps-1.2.jar)  and see if the XML support that I assume Jetty needs 
anyway will be accessible to the webapp classloader (it should...)

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>