JSP at GlassFish
Native PHP in Glassfish with jsr223
Previously, Ludo and Arun described how to run PHP 5 on GlassFish using Quercus, see here and here. However, it is also possible to invoke the native PHP engine on Glassfish, using jsr223 and a PHP bridge. The following steps should work on Sparc Solaris 10.
- Download script.jar and drop it into <glassfish>/lib.
- Download libphp5-5.0.1-sparc-S2.so, save it as libphp5.so and drop it into <glassfish>/lib.
- Download phptest.war and deploy in Glassfish.
- Run the php.
Of course you can run your php program similarly, just be sure to copy the php servlet mapping into your web.xml.
I built these two files from a Sun internal repository for Jsr223, there may be binaries available publicly, but I can't seem to find them.
Note that version that libphp5.so is 5.0.1, and I have only built it on the Sparc Solaris 10.
It'll be interesting to compare the performance for running PHP on Glassfish, using Quercus and using native PHP. It would also be interesting to compare the performance of Glassfish+PHP with Apache+PHP.
Posted at 03:37PM Feb 15, 2008 by kchung in Sun |
Speed up JSP compilations in GlassFish with JSR 199 Java Compiler Interface
A frequent complaint about web application development is the speed (or lack of) of compiling JSP pages, and a major portion of JSP compilation time is spent in compiling the generated Java files.
In GlassFish, Java compilations are handled with ant, and for reasons I won't get into now, with fork option as the default. This really slow down the compilation.
The reason for using ant to invoke javac is that there is no standard API for invoking it. Well, not until now, that is. JSR 199, Java Compiler API, is now part of Mustang, and starting with b11, GlassFish now supports it for JSP compilations!
To turn on JSR 199 support, take the following steps.
- Use Java SE 6 (code name Mustang) in GlassFish. To do that, the file asenv.conf in ${GF_HOME}/config/asenv.conf needs to be edited to set AS_JAVA to point to Mustang, before starting the appserver.
- Download jasper-jsr199.jar and drop it into ${GF_HOME}/lib. This jar provides the code in jasper that invokes Mustang for java compilations.
The performance gain for using JSR1 199 API is amazing! Preliminary measurement shows an order of magnitude improvement in raw Javac compilation speed, and a 3.5X improvement in overall execution when running JSP TCK tests!
With JSR 199 support in Jasper, the generated Java files and the generated class files are both kept in memory, avoiding unnecessary disk I/Os. The fact that the class files are actual byte arrays makes bytecodes processing (such as SMAP generation and bytecode preprocessing) and class loading much more efficient, as they can all be done in memory.
One other performance work that I haven't done yet is to cache the system jars used in java compilations. Doing this would effectively create a compiler server for the web container. Since this may also have scalability and usability issues, I'll need to experiment to see if this effort is worthwile.
Posted at 02:00PM Jul 31, 2006 by kchung in Sun | Comments[2]
Backward Compatibility of Gassfish with JSF 1.0 Applications
One of the goals of JSP 2.1 is to provide a unified expression language (EL) for JSP and JSF. One key feature of the unified EL is the introduction of deferred expressions. Deferred expressions was first used in JSF 1.0, which used the syntax #{...} to represent a deferred expression. The same syntax is used in JSP 2.1, to ease migration of JSF 1.0 and JSF 1.1 applications to JSF 1.2, bundled in Glassfish.
Additionally, it is imperative that a JSF 1.0 applications can be deployed without modification in Glassfish. A JSF 1.0 application typically runs with JSP version 2.0 or earlier. In JSP 2.0, specifying a "#{...}" as a tag attribute has no special meaning, and the literal string is passed to the tag handler without any processing by the container. In contrast, in JSP 2.1, the compiled version of "#{...}" is passed to the tag handler. To maintain backward compatibility, the JSP container in Glassfish must handle "#{...}" in a JSF 1.0 application as a literal.
Fortunately for us, there is a required "jspversion" tag in the tag library descriptor (TLD) for a tag handler. Based on jspversion in the TLD, the container can then decide to either compile the deferred expression, or to pass the string unchanged.
All this has been working in Glassfish up to build 32 (the one the appserver 9.0 beta was based). Unfortunately, a regression was introduced in b34 which causes the container to (wrongly) issue an error when encountering "#{...}" in a tag attribute. This has been fixed b36.
Posted at 03:52PM Feb 01, 2006 by kchung in Sun |
JSPWiki and GlassFish
Servlets and JavaServer Pages are nothing new, but they are still important components for building web applications. Since they are part of Java EE, applications built with them are completely portable across Java EE containers. JSPWiki is the latest example that I ran across.
JSPWiki is a WikiWiki engine built around servlets and JSPs. It uses AS8.1 for the development. Just out of curiosity, I downloaded a version and installed it with GlassFish, and it just worked!
The intallation cannot be any simpler. After I unzipped the downloaded files, I copied JSPWiki.war to GlassFish's autodeploy directory. I then used the URL http://localhost:8080/JSPWiki/install.jsp to set up the initial configurations (specfying the base Wiki URL, file storage and log files etc.). After I restarted GlassFish, the Wiki page (I used the default http://localhost:8080/JSPWiki) was ready for use. I was able to create and edit pages with links.
JSPWiki is an active open source project and people are busy adding plugins, filters and other functionalities. One feature I like is its simplicity: plain files are used for storage, though there other PageProvider (such as one using mySQL) that are contributed.
I'll play with it more and blog more about it later.
Posted at 03:36PM Dec 16, 2005 by kchung in Sun | Comments[1]