Thursday Nov 15, 2007

Where did my Servlets Go? JSP, JSR199 and GlassFish

Image of Waldo

One of the benefits of using JSR-199 in GlassFish is Very Fast JSP compilation: the generated Servlets can be passed directly, in-memory, to javac. But if you really want to see what's going on you have a problem, as shown by this long mail thread: there is no Servlet code to see because writing it to disk would defeat most of the benefits of JSR-199!

The solution is easy: ask GlassFish to write the Servlet code go to disk using the keepgenerated parameter. Check out Byron's note for the details.

Wednesday Jun 20, 2007

SJS Web Server 7.0 Update 1 is out - Focus on Java

Sun Web Server 7.0 Update 1

Sun Java System Web Server 7.0 update 1 is now available for download (the preview version had been available for a few months). New in this release is:

• Performance and stability improvements
• Out-of-box Java support for Servlets 2.5, JSP 2.1, JSF 1.2, and more
• Support for Java SE 5.0 and 6
• Support for NetBeans IDE 5.5.1
• Administration interface support for FastCGI

You'll notice that the main features are Java-related. Specifically, the product is now at the Java EE 5 specification level which means that any web application that runs on GlassFish now also runs on Sun's Web Server 7.0 Update 1 (the implementation is actually taken straight from GlassFish). On the more technical side of things, you can use dependency injection in the web tier.

When released in early 2007, Web Server 7.0 enjoyed an excellent review and has been powering a whole new set of demanding web sites (including the one serving you this content). Any question, see the dedicated forum.

Thursday Apr 05, 2007

notd - Performance of Servlet Containers - Partial Addendum to Covalent blog

Mark Twain

Covalent recently published some benchmark results on the scalability of 3 popular Servlet containers: Tomcat 6 using the native APR, Jetty and GlassFish. The results are good for the three, but they favor TC 6 when using a very large number of connections.

One danger with performance tests is that is is really hard to make accurate comparisons, despite everybodies' best intentions. For example, inside Sun I've been involved in comparisons between the Web Server and GlassFish and the results are affected by details like how many requests, what response time, what percentage of successful responses, how much memory, what tuning parameters, etc. That is why there are organizations like SPEC and benchmarks like Web2005 and SPECjAppserver (and even those have their own issues).

The Covalent piece is doing a good job in that it is dispelling the myth that Servlet containers do not scale, because it is forcing teams to provide better out of the box performance (Java SE 6 did a great job there) and because I think everybody will be more careful measuring performance. I'd expect improvements on all these fronts in the near future, in the meantime, here are some additional pointers you may want to check out...

• AB Considered Harmful
• Configuring Grizzly for Performance: Part I, Part II
• Comments from Greg W regarding Jetty in that Covalent article.

Regarding the picture, I chose Mark Twain because (a) he popularized the phrase Lies, Damned Lies, and Statistics and (b) he is such a great guy that we should have him somewhere in TheAquarium, but please do note that I am not saying that the covalent blog are lies! :-)

Wednesday Jan 17, 2007

Servlets in 4 languages with Sun's Web Server

Monty Python's - Something Completely Different

Rahul has an interesting series of detailed blogs that show how to use different JVM-based scripting languages to write Servlets on Sun's WebServer 7.0 (download) even when using plain J2SE 5 (this is easier in Java SE 6 through JSR 223). The series includes a prologue providing some common code for all the languages and then specific and very detailed entries for jRuby, jScheme, Rhyno and Sleep.

And, Now For Something Completely Different...

All these use the in-memory JVM from the WebServer, but... Rahul also shows how to use FastCGI to call native Ruby directly.