I managed (I think) to solve my problem. XMLC has some classes to optimise things by only expanding (btw: could someone explain to me what they actually mean by that as Im not an xml guru) certain nodes. They call this LazyDom. The classes involved dont seem to work when a version of xerces greater then 1.2 is used. If I put xmlc.jar and xerces-1.2.jar in my tomcat common/lib everything works fine. I dont see this as a particularly good idea however. xmlc also has an option to switch off this lazy dom stuff (use -dom xerces) which makes it use only the normal dom classes. This seems to work ok with later versions of xerces, so I can put a higher version of xerces and the xmlc jar in my web-inf/lib and it all works fine. I gather there is something of a performance hit for not using lazyDom, but Im not sure how bad it is yet. (btw: I read somewhere the tomcat4.0.3 doesnt allow parsers in web-inf/lib. Does this mean my xmlc generated code is merely availing itself of the classes in web-inf/lib/xerces.jar but that struts is using whatever parser is in common/lib to do its xml parsing?) Anyhow, Im hoping that it will now work well enough for me to ditch the idea of using jsps for my view, and instead have my action forward to a servlet once its assembled all the dynamic stuff , and the servlet will concentrate on rendering the dynamic stuff into the dom provided by the xmlc generated class. I was thinking of making that servlet a rather generic one, and having my action select an appropriate class to do this rendering, which the servlet would instantiate (or get from a cache) and delegate the rendering to. (Come to think of it that could be an action rather than a servlet too?). Anyone have any advice, comments about this idea?
-----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 07, 2002 22:27 To: Struts Subject: Struts & XMLC (xml parser conflict issues) I wish to use XMLC to implement the view in my struts application however I am experiencing problems when I include the xmlc.jar inside my WEB-INF/lib directory. As far as I can make out this is due to having different versions of the same XML parser & DOM classes in various jars. When starting TomCat4.03 the following exceptions are reported: javax.servlet.UnavailableException: Parsing error processing resource path /WEB-INF/struts-config.xml at org.apache.struts.action.ActionServlet.initApplicationConfig(ActionServlet.j ava:780) at org.apache.struts.action.ActionServlet.init(ActionServlet.java:417) ..etc and also: javax.servlet.ServletException: Servlet.init() for servlet jsp threw exception at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:93 5) ...etc ----- Root Cause ----- java.lang.NoClassDefFoundError: org/w3c/dom/range/DocumentRange at java.lang.ClassLoader.defineClass0(Native Method) ...etc As the struts-config could not be parsed the application is dead. It seems that enhydra extended an older version of xerces when they created xmlc and struts tries to use these classes instead of the xerces in common/lib (btw: is it supposed to be there or should it be in WEB-INF/lib too??). I tried dumping a copy of xerces in my WEB-INF/lib which made struts work again, but my page that uses xmlc (my trying to use an xmlc generated class from a tag) dies with: javax.servlet.ServletException: (class: org/enhydra/xml/lazydom/LazyElementNoNS, method: expandAttributes signature: ()V) Incompatible object argument for function call at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImp l.java:463) ..etc (Incidentally I have a small snippet of code in a main() function that does (roughly) the same thing as the other code in the tag and works fine when run as a normal java class: //The following being in doEndTag(): Test test = new Test(true); // Test being a 'hello world' type class generated using xmlc JspWriter out = pageContext.getOut(); out.write(test.toDocument()); ) Anyone can advice me as to the approach I should take towards resolving this? thanks Andrew -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
