You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Glen Mazza <gl...@gmail.com> on 2013/04/13 15:47:55 UTC
Remove the Tomcat JSP precompile tasks?
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 <gl...@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/>- 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/>- 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
>>
>>
Re: Remove the Tomcat JSP precompile tasks?
Posted by Glen Mazza <gl...@gmail.com>.
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 <ha...@gmail.com> wrote:
>
>> I personally never used it , +1 on removing it.
>>
>> regards,
>> Harry
>>
>>
>>
>> On 13 April 2013 15:47, Glen Mazza <gl...@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 <gl...@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
Re: Remove the Tomcat JSP precompile tasks?
Posted by Andrew Jaquith <an...@gmail.com>.
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 <ha...@gmail.com> wrote:
> I personally never used it , +1 on removing it.
>
> regards,
> Harry
>
>
>
> On 13 April 2013 15:47, Glen Mazza <gl...@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 <gl...@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
>>
Re: Remove the Tomcat JSP precompile tasks?
Posted by Harry Metske <ha...@gmail.com>.
I personally never used it , +1 on removing it.
regards,
Harry
On 13 April 2013 15:47, Glen Mazza <gl...@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 <gl...@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
>>>
>>>
>>>
>