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>