OK, I removed it. This shrunk the build.xml about 10%.
Glen
On 04/13/2013 01:26 PM, Andrew Jaquith wrote:
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 <[email protected]> wrote:
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
