I personally never used it , +1 on removing it. regards, Harry
On 13 April 2013 15:47, Glen Mazza <[email protected]> wrote: > Anyone mind if we get rid of the Tomcat JSP precompile option in the > build.xml? It's of limited usefulness today (we're presently compiling > with old Tomcat 5.x stuff), the presence of Tomcat 5.x stuff makes the > project look old, and the tasks involved just add a lot of bloat to the > build.xml file. According to the build.xml: > > <!-- This target builds a WAR file that is specially pre-compiled > for use with Tomcat. By generating and pre-compiling JSPs > ahead of time (instead of having Tomcat do it on-the-fly > at runtime), we provide a slight runtime speed bump. In > addition, in security-conscious environments this means > that we can eliminate the need for the Jasper JSP compiler, > and can run Tomcat using just a JRE instead of a full JDK. > > The "slight runtime speed bump" is only for startup after initial > deployment but even then JSPWiki is quite zippy, performance is not an > issue. As for security, I really doubt "security conscious environments" > are going to rely on end-of-life Tomcat 5.0-precompiled JSPs but will > instead precompile it *themselves* with the precise JDK and servlet > container versions they are using in production (not everyone is using > Tomcat, and even those who are are mostly on Tomcat 7 today). How to > precompile JSPs is a servlet container (& potentially servlet container > version) specific process for *any* WAR (not just JSPWiki) and users need > to consult their app server-specific documentation for the precise and > secure way of doing that, for those who actually care about doing so. Even > on the Maven side, the corresponding plugin stops at Tomcat 6: > http://mojo.codehaus.org/jspc/**, i.e., people just aren't doing this > that much today. > > Regards, > Glen > > On 04/03/2013 03:43 PM, Juan Pablo Santos Rodríguez wrote: > >> Hi Glen, >> >> the precompile JSPs option is available through the *-tomcat targets (line >> 1124 onwards) on build.xml, and are meant to enable running the webapp >> with >> only a JRE, instead of a JDK. They're not part of the main build, so it >> doesn't seem related to me. >> >> The org.gjt.xpp seems odd to me though, where does it comes from (maybe >> the >> xerces jars)? Can you try specifying the jaxen dependency as: >> >> <dependency> >> <groupId>jaxen</groupId> >> <artifactId>jaxen</artifactId> >> <version>1.1-beta-6</version> >> <exclusions> >> <exclusion> >> <groupId>*</groupId> >> <artifactId>*</artifactId> >> </exclusion> >> </exclusions> >> </dependency> >> >> to see if it helps? Right now I'm not on my pc so I'm unable to try it >> >> HTH, >> juan pablo >> >> On Wed, Apr 3, 2013 at 12:00 AM, Glen Mazza <[email protected]> wrote: >> >> Hi folks, "mvn clean install" and "ant war" will now create nearly >>> identical WARs (differing only in the WEB-INF/lib folder) -- but ATM only >>> the latter still works. I think it's something related to the precompiled >>> JSPs (which the Maven WAR doesn't rely on presently, but I'm not sure >>> where >>> they are in the Ant WAR, so???) When running the Mavenized version, the >>> JSPWiki log files are reporting: >>> >>> 2013-04-02 17:29:51,149 [http-bio-8080-exec-6] WARN >>> org.apache.wiki.tags.* >>> *WikiTagBase JSPWiki:/JSPWiki/ JSPWiki:http://localhost:8080/** >>> **JSPWiki/ <http://localhost:8080/**JSPWiki/><http://localhost:** >>> 8080/JSPWiki/ <http://localhost:8080/JSPWiki/>>- Including failed, got >>> a servlet exception from sub-page. Rethrowing the >>> exception to the JSP engine. >>> org.apache.jasper.****JasperException: <h3>Validation error messages >>> from >>> TagLibraryValidator for fmt in /templates/default/UserBox.**** >>> jsp</h3><p>null: >>> org.xml.sax.SAXParseException; lineNumber: 206; columnNumber: 15; parsing >>> error: org.gjt.xpp.****XmlPullParserException: end tag name should be >>> wiki:Translate not fmt:message at line 206 and column 15 seen >>> "...</jsp:text>\n</fmt:****message"... (parser state END_TAG)</p> >>> at org.apache.jasper.compiler.****DefaultErrorHandler.jspError(**** >>> DefaultErrorHandler.java:56) >>> at org.apache.jasper.compiler.****ErrorDispatcher.dispatch(** >>> ErrorDispatcher.java:410) >>> at org.apache.jasper.compiler.****ErrorDispatcher.jspError(** >>> ErrorDispatcher.java:75) >>> >>> and >>> >>> at java.lang.Thread.run(Thread.****java:722) >>> 2013-04-02 17:29:51,833 [http-bio-8080-exec-6] WARN >>> org.apache.wiki.tags.* >>> *WikiTagBase JSPWiki:/JSPWiki/ JSPWiki:http://localhost:8080/** >>> **JSPWiki/ <http://localhost:8080/**JSPWiki/><http://localhost:** >>> 8080/JSPWiki/ <http://localhost:8080/JSPWiki/>>- Including failed, got >>> a servlet exception from sub-page. Rethrowing the >>> exception to the JSP engine. >>> org.apache.jasper.****JasperException: java.lang.**** >>> ClassNotFoundException: >>> org.apache.jsp.templates.****default_.UserBox_jsp >>> at org.apache.jasper.servlet.****JspServletWrapper.getServlet(**** >>> JspServletWrapper.java:177) >>> at org.apache.jasper.servlet.****JspServletWrapper.service(** >>> JspServletWrapper.java:369) >>> >>> The Mavenized version of http://localhost:8080/JSPWiki will still >>> activate but the front page text is not visible (only the headers and >>> footers show). I'll look into this next but if anyone can see what's >>> immediately wrong with the Maven WAR (and optionally wants to fix it), >>> please go ahead. >>> >>> Another issue the WEB-INF/libs/*.JARs are mostly but not completely >>> identical between the Ant and Maven WARs because with Maven dependency >>> resolution, additional JARs needed by those declared dependencies are >>> brought in (unless we explicitly exclude them) while our Ant scripts will >>> not use JARs that we don't manually configure. In particular the Jaxen >>> dependency ends up bringing in 11 additional dependencies that the Ant >>> build skips (upping the JAR count from 31 jars to 43), here are some but >>> not all of them (you can see them by running mvn dependency:tree): >>> >>> [INFO] +- jaxen:jaxen:jar:1.1-beta-6:****compile >>> [INFO] | +- dom4j:dom4j:jar:1.5.2:compile >>> [INFO] | | \- jaxme:jaxme-api:jar:0.3:****compile >>> [INFO] | +- xerces:xmlParserAPIs:jar:2.6.****2:compile >>> [INFO] | +- xerces:xercesImpl:jar:2.4.0:****compile >>> [INFO] | \- xom:xom:jar:1.0b3:compile >>> [INFO] | +- com.ibm.icu:icu4j:jar:2.6.1:****compile >>> [INFO] | +- xalan:xalan:jar:2.6.0:compile >>> [INFO] | | \- xml-apis:xml-apis:jar:1.0.b2:****compile >>> [INFO] | \- org.ccil.cowan.tagsoup:****tagsoup:jar:0.9.7:compile >>> >>> Do we need Jaxen today in JSPWiki anyway? I just see RPCHandlerTest >>> failing if I don't include it. As I understand, Jaxen was best in the >>> pre-JDK 5.0 days when there was no default XPath parser in the JDK. If >>> we >>> can rely on what the JDK supplies by default for XPath processing we can >>> remove a lot of extra JARs from the Maven-built WAR. >>> >>> Besides these, there are 4 more JARs that Maven is determining necessary: >>> jakarta-regexp-1.4.jar used by lucene-queries, >>> lucene-queries used by lucene-highlighter, xpp3 used by sandler, and >>> xerces used by nekohtml. >>> >>> Finally, IIRC we had earlier determined that Stripes was not needed in >>> the >>> WAR (it's just used during running the test cases), so I removed it from >>> the "war" task in the Ant build.xml. If I'm incorrect on this, we can >>> put >>> it back in. >>> >>> Regards, >>> Glen >>> >>> >>> >
