incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harry Metske <harry.met...@gmail.com>
Subject Re: Remove the Tomcat JSP precompile tasks?
Date Sat, 13 Apr 2013 15:51:09 GMT
I personally never used it , +1 on removing it.

regards,
Harry



On 13 April 2013 15:47, Glen Mazza <glen.mazza@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.mazza@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
>>>
>>>
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message