Yeah, I implemented it and wrote that text. I don't think the project would suffer from it removal. ;)
+1 On Apr 13, 2013, at 11:51 AM, Harry Metske <harry.met...@gmail.com> wrote: > I personally never used it , +1 on removing it. > > regards, > Harry > > > > On 13 April 2013 15:47, Glen Mazza <glen.ma...@gmail.com> 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 <glen.ma...@gmail.com> 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 >>
