Following extensive redesign and refactoring, the Tomcat team recently announced the first release of the new Tomcat 5.5 branch. This release sports increased performance and an improved internal structure. Yoav Shapira, of the Tomcat team, was interviewed about the new features and internal structure.

Yoav talks about:

• The stability of Tomcat 5.5.1
• Why the team ported Tomcat to use Eclipse JDT instead of the Sun JDK
• Commons-Logging :/
• Other proprietary parts of Tomcat which may get externalized
• Server startup time
• Tomcat 6

Read the full interview: Dallying with Tomcat 5.5

even though I keep track of tomcat-dev, it is nice to have an interview that covers the changes and gives normal users a better view of tomcat and where it's going.

I'm glad to see the team will be spending more time and effort on documentation and usability. I think this makes all the difference in open-source software.

I think forums and FAQs are a better way than mailing lists to share the knowledge of the community and get feedback from the developers. I'm not too keen to join a mailing list and get even more emails in my inbox. Usually, the mailing list archives don't provide a great search function either.

Forums provide an easier way to browse by topics or search for specific information.

The ability to load JSP's from StringBuffers/CharArrays rather than just the filesystem.

The ability to load JSP's from StringBuffers/CharArrays rather than just the filesystem.

I suppose tomcat could implement it and have it be optional. I don't think it violates the spec, since a user can deploy a webapp without extracting the war file. Does that qualify as loading from stringbuffer?

The ability to load JSP's from StringBuffers/CharArrays rather than just the filesystem.

I suppose tomcat could implement it and have it be optional. I don't think it violates the spec, since a user can deploy a webapp without extracting the war file. Does that qualify as loading from stringbuffer?

JSP have to be compiled after each change. So, JSP source is designed to be static and usability of dynamic JSP is limited.

JSP have to be compiled after each change. So, JSP source is designed to be static and usability of dynamic JSP is limited.

Not everyone uses Jasper .. have you ever looked at what it generates? :-o

Furthermore, just because the current implementation of JSP -> Servlet conversion in Tomcat is relatively static and slow doesn't mean that it has to always stay that way.

The real question is this: Why does dynamic JSP loading make sense? Does it help solve real problems? If so, someone will find a good way to make it work well.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Not sure if this is what you mean, but for my work we implemented a restricted JSP engine that compiled a String (of JSP text) to a tree of nodes (text/directive/tag). The nodes could then be processed in the same way as JSP to produce an output string.

The main restriction was that the JSP couldn't contain java code. Everything had to be done via tags. This suits our coding standards ;-)

The mechanism is actually quite fast, and is very useful for generating emails using jsp sytax and tags. It also produces very good debugging messages (a la line-precise error reporting from tapestry). It also seems to be faster than jasper to read and compile a page, until you get into production, when the heavier loading favours a compiled JSP.

Its closed source though :-(, but maybe the idea might inspire someone at tomcat?

As Cameron said, the real question is where the need comes from. If there's a real and common need for compiling JSPs from in-memory stringbuffers or whatever, then it'll get implemented. This is the first time I see such a request after more than four years of monitoring the Tomcat mailing lists closely.

I also like to give the JSP Expert Group folks credit and assume they've considered this case before they came up with the Spec or later when they released updated versions of the Spec. But perhaps my faith is misplaced, or this was never discussed in detail, I don't know ;) Obviously, Tomcat implements the JSP Spec completely, so if the Spec mandated what you're asking for then it would be in Tomcat.

As to the comment that not everyone uses Jasper -- that's right of course, as virtually no product has 100% of any market ;) But Jasper does have a huge user base. It's embedded in Jetty, JBoss, WebSphere, JonAS, and some smaller products, so it's not only Tomcat users that rely on Jasper. And you don't hear performance complaints often to boot, so I'll give credit for that to Jasper's developers (I myself only implementede extremely minor feature additions to it, none of the core stuff).

I'm intrigued by Senor Colebourne's "restricted JSP engine". Sounds interesting -- maybe a good Jakarta Commons project?

As to the comment that not everyone uses Jasper -- that's right of course, as virtually no product has 100% of any market ;) But Jasper does have a huge user base. It's embedded in Jetty, JBoss, WebSphere, JonAS, and some smaller products, so it's not only Tomcat users that rely on Jasper. And you don't hear performance complaints often to boot, so I'll give credit for that to Jasper's developers (I myself only implementede extremely minor feature additions to it, none of the core stuff).

If basically everyone uses Jasper, you wouldn't hear about performance issues.

However, I suggest that anyone wanting to understand more about the potential performance gains -- were Jasper better optimized -- should compare the Jasper output against say Caucho Resin's JSP compilation.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Not everyone uses Jasper .. have you ever looked at what it generates? :-oFurthermore, just because the current implementation of JSP -> Servlet conversion in Tomcat is relatively static and slow doesn't mean that it has to always stay that way.The real question is this: Why does dynamic JSP loading make sense? Does it help solve real problems? If so, someone will find a good way to make it work well.Peace,Cameron Purdy

Jasper generates Java code, so after Jasper there is javac, then class loader, JIT and class garbage collector (or memory leak :). You can't avoid java compilation if you don't restrict JSP not to use Java scriplets. Compiling JSP on each request is too costly anyway.

Dynamic JSP make sence in content management systems where JSPs should be stored in database, but you don't change JSPs to frequently.

If you need truly dynamic templates, then consider alternative template engine like Velocity (or container based on more dynamic programming language like Zope :)

Nebojsa

Jasper generates Java code, so after Jasper there is javac, then class loader, JIT and class garbage collector (or memory leak :). You can't avoid java compilation if you don't restrict JSP not to use Java scriplets. Compiling JSP on each request is too costly anyway.

What are you talking about: "compiling it on each request"? I don't remember anyone asking for such a silly thing.

The problem is that doing it the "Jasper" way is slow both for compilation and actually running the JSPs. Please don't limit the imagination of the market place by constraining it to use such a poorly implemented approach.

A substantial JSP file can be parsed and compiled (.class) and loaded into a running JVM in a small fraction of a second. That it takes several seconds with various shipping products (e.g. Tomcat) is a travesty, and simply indicates that they never bothered to try to make it performant. Further, that the code produced is so sub-standard as to be cringeworthy.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

What are you talking about: "compiling it on each request"? I don't remember anyone asking for such a silly thing.

When you generate something dynamically, it isn't unusual to generate it on each request. If you generate JSP on each request, then you will compile it also.

Nebojsa

When you generate something dynamically, it isn't unusual to generate it on each request. If you generate JSP on each request, then you will compile it also.

They are two different things. While it is possible that you could occasionally be correct, decrying dynamic content generation because someone could theoretically mis-use it is a great excuse to stay with COBOL ;-)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

They are two different things. While it is possible that you could occasionally be correct, decrying dynamic content generation because someone could theoretically mis-use it is a great excuse to stay with COBOL ;-)

Read my posts more carefully. I have said that usability of dynamic JSP is limited and that dynamic JSP make sense in content management systems where JSPs should be stored in database, but you don't change JSPs to frequently.

Considering any example you don't like as misusing is a great excuse to stay with COBOL ;-)

Nebojsa

What are you talking about: "compiling it on each request"? I don't remember anyone asking for such a silly thing.The problem is that doing it the "Jasper" way is slow both for compilation and actually running the JSPs. Please don't limit the imagination of the market place by constraining it to use such a poorly implemented approach.A substantial JSP file can be parsed and compiled (.class) and loaded into a running JVM in a small fraction of a second. That it takes several seconds with various shipping products (e.g. Tomcat) is a travesty, and simply indicates that they never bothered to try to make it performant. Further, that the code produced is so sub-standard as to be cringeworthy.

Since I follow tomcat development, I can say that is categorically not true. Remy and several other people have tried to improve Tomcat's performance. Tomcat5 is pretty much equal to the top servlet containers today. I've compared the source generated by Jasper vs Resin and resin is impressive. One particular example is Resin's Fast JSTL, which is faster than jakarta JSTL. Having done quite a bit of benchmarks on tomcat, I can say that jasper is neither slow or super fast. In terms of runtime performance, the biggest bottleneck in compiled JSP is jsp tags. Jsp compilers that convert tags to pure java code definitely run faster, but strictly speaking they aren't tags and don't operate the same way.

the guys who wrote Jasper2 considered generating pure java for tags, but ultimately they couldn't. to comply with the spec, Jasper2 has to compile the page a certain way. Resin gets better performance, because they don't strive for 100% compliance to the spec. That's great in my mind, because it gives me a choice. there's a little known feature in Jasper2 for converting tags to pure java http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper/docs/api/index.html.

very few people aside from tomcat developers and those who follow it closely know of it. There's definitely room for improvement in Jasper, but when you take into consideration, the expression language, file tags, normal jsp tags and scriplet code in a single JSP, I prefer the page compiler handles it rigorously. I don't think it would be possible to improve jasper compilation 3x and still maintain the same level of rigor in terms of compliance to the specs. I could be wrong.

That it takes several seconds with various shipping products (e.g. Tomcat) is a travesty, and simply indicates that they never bothered to try to make it performant.

I set my client's network timeout at 5 seconds because I was told not to make users wait longer. Usually Tomcat makes my client time out on the first request to a JSP that wasn't loaded. My acceptance tests always send the first request twice. Is there an easy way (Ant tasks or deployment descriptor tweaks) to precompile and preload a web application into Tomcat? And would it make a noticable difference?

That it takes several seconds with various shipping products (e.g. Tomcat) is a travesty, and simply indicates that they never bothered to try to make it performant.

I set my client's network timeout at 5 seconds because I was told not to make users wait longer. Usually Tomcat makes my client time out on the first request to a JSP that wasn't loaded. My acceptance tests always send the first request twice. Is there an easy way (Ant tasks or deployment descriptor tweaks) to precompile and preload a web application into Tomcat? And would it make a noticable difference?

Hi, You can use JSPCompiler that comes with Jasper. Infact we use the same in our production environment, we precompile every JSP, before it gets shipped to production.

Hmm, not everything lives in the filesystem.

JSP could be loaded from a DBMS, or in my case from XML documents.

Forums are a good and interesting idea. The mailing list works, and if you have a threaded mail reader you can quickly look for only issues that interest you. But a Forum provides a nice alternative, so we'll keep that in mind.

I find the MARC (http://marc.theaimsgroup.com/) archives to be complete, timely, and nicely searchable. The Jakarta site (http://jakarta.apache.org/site/mail.html) lists othe archives which offer different search features.

We've also seen a marked increase in people reading the list, searching the list, and posting to the list via the GMane gateway (e.g. http://news.gmane.org/index.php?prefix=gmane.comp.jakarta.tomcat).

One of the desired feature of tomcat 5.5 for me is the elimination of the Apache web server fronting requirement for scalable web sites for tomcat. If a NIO based HTTP/1.1 connector is available which can do scaleably Keep Alive handling for hundreds of slow living connections, it will be sweat.

This http://www.janino.net/ looks pretty usefull.