Tomcat 5.0 Released

aquarium writes "The Apache Jakarta Project announces the release of the first stable version of Tomcat 5.0. Improvements include performance optimizations, scalability and reliability enhancements, and improved Taglibs handling."

Comments

JSP sites and Tomcat

[Trbmxfz]

The idea of using a language like Java to build webpages seems interesting, at least because Java is designed to scale well on big programs. Perl at least scales just fine; I don't know about PHP though.

It's interesting to note that Linux (probably with Apache's Tomcat) is a very popular system for JavaServer Pages (where one would have expected Sun's own Solaris platform to be popular). There is an article at Netcraft (from July) that summarizes the situation:

JSP continues to enjoy fast growth with a 94% increase in ip addresses running JSP based sites to over 44,000 ip addresses running some 105,000 active sites.

More surprising is the composition of these sites choice of operating systems. One might expect that by far the most common operating system amongst JSP based sites would be Solaris, (...). However, Solaris is only placed 3rd with 17% behind Linux with 40% and Windows with 26%.

Re:JSP sites and Tomcat

[brainlounge]

Why should Solaris be the leading Java OS? Only because Sun delivers both?

Following this logic would impose the question why no IBM OS shows up in the first ranks although they provide a Java implementation as well.

I think this figures more or less represent Java's overall OS-related deployment numbers (on Server machines).

Re:JSP sites and Tomcat

[Anonymous Coward]

The Java VM on Solaris isn't particularly good. Funny enough, Sun's VM written for Windows performs much better.

This could explain that.

Re:JSP sites and Tomcat

[makapuf]

> Java is designed to scale well on big programs

How exactly is a language designed to scale well ? In LoC ?
Sorry but, while J2EE might be designed to scale well, Java is a language, and beyond that, was not designed for scalability, but portability. Remember it was an embedded language on the beginning.

Re:JSP sites and Tomcat

[brainlounge]

> Java is designed to scale well on big programs

Read: "Java's Virtual Machine (JVM) is designed to scale well on big programs"

Re:JSP sites and Tomcat

[the quick brown fox]

I am by no means an expert on the subject, but I'm pretty sure language designers can and do take performance and "scalability" (whatever OP means by that) into account.

For example, Java uses a hybrid type system where most values (strings, array) are objects and have by-reference semantics, but primitive values (ints, longs, doubles, bools, etc.) do not behave as objects and have by-value semantics. It's less elegant for the programmer than some other languages (Smalltalk, Ruby, others?) where Everything Is An Object, but makes a big difference for performance and memory consumption (and memory usage patterns).

The Java language spec also goes into quite some effort to specify a threading model. IMO this is a great boon for people who want to build serious servers in Java... contrast this to many scripting languages, which (appropriately, perhaps) seem to treat concurrent programming as an afterthought.

Or if you take a look at Bjarne Stroustrup's Design and Evolution of C++, he mercilessly rejects adding any language feature that cannot be implemented without slowing down code that doesn't use the new feature. (I can't think of any examples right now, and I can't find my copy.)

Re:JSP sites and Tomcat

[weo]

Java is more than just a language. It is an API, byte code and VM. The API is designed for scaleablity and the HotSpot VM was designed to improve performance of compiled code as it is being run.

Re:JSP sites and Tomcat

[JohnFluxx]

That was what a the whole sun-MS lawsuit was about.

MS modified the VM to make it run a lot better, but Sun were control freaks and didn't like that and refused to make the changes themselves..

In summary imagine two huge control freaks clashing...

Re:JSP sites and Tomcat

[Kailden]

Haven't worked much with Solaris, but I've always heard that the VM on solaris has more ways to 'tweak' garbage collection and does pretty good threading. True? Not True?

Re:JSP sites and Tomcat

[Kailden]

I guess I always took 'scalable' in this case to mean someting closer to enterprisish capability.

What I mean by this is it is easier in java to organize and build a complex application by wrapping business logic and typical data access deep inside generic objects (beans)....then you can focus on the framework and organization and the modularity allows you to separate out tasks well.

This is not for every application, but for the big ones that handle lots of access points (procurement/supply chain/accounting/planning) and lots of function (messaging, transactions, forecasting, reporting) that is all part of one big system, then its probably easier for a lot of people to work together on the Java than it is for a bunch of perl/php scripts.

Then again, the chance of your company working on such a system is less likely then them buying into SAP or one of the other big ones.

For most small stuff, perl and php are fine.
With the right programming group, perl and php can work on large projects too.
But for the average large company, with a big system, Java seems to work well in architecture and implementation of the system. It will also probably take LONGER to implement. (expecially if you use beans to encompass all the real logic and jsp just for presentation and servlets just for the HTTP interface) YMMV.

I've written ASP run sites, Java Servlet run sites, currently working on a Perl CGI::APP + template toolkit site, and have messed around PHP and Zope/Python. As with anything else, its all about using the right tool FOR THE TEAM for the job.

Java, though, in lots of corporate development shops, seems to be given an unwarranted buzzword boost from managers who set it as a requirement across the board.

Re:JSP sites and Tomcat

[Anonymous Coward]

Actually you are as incorrect as it is possible to be incorrect. The reason the solaris java vm sucks compared to the linux or windows versions is because the windows and linux versions get far more development and the solaris version since they are the primary platforms that are used (obviously).

Re:JSP sites and Tomcat

[hlee]

Well, Java is both the language and a virtual machine. Designing a scalable VM is tricky - for example, this article (http://java.sun.com/docs/hotspot/gc/) discusses how garbage collection degrades with the number of processors available. Sun has done a fair amount of research like this to ensure the VM scales, or at least to the extent we understand the tradeoffs when tuning an application (esp. 1.4 VMs).

Re:JSP sites and Tomcat

[antc3]

Actually that's not true. Sun sued Microsoft over changes they made in thier implementation of the Java Language not the JVM. At issue were things like the Microsoft only delegate keyword that did not exist on other platforms.

When one of your selling points is "write once, run everywhere" you don't want one of your licensees adding new keywords to your language.

Re:JSP sites and Tomcat

[zipwow]

Will this thing ever die?

Two years ago, (almost three), Java performance on Solaris wasn't very good. Why? Because it didn't need to be. As this article points out, Sun had better things to do two years ago than tune the JVM on a platform that it wasn't being used for.

If anything, this memo is an example of how things are working properly. Engineers complained, and things changed. If you look at some of the modern benchmarking linked from the provided site rather than ancient gossip, you'll see that the Solaris JVM is on par with the Windows JVM. Granted, they both need improvement in memory footprint and startup time, but the point still stands, the Solaris JVM is not lagging behind the Windows implementation.

Its time we put this one to bed.

-Zipwow

Re:JSP sites and Tomcat

[betelgeuse68]

Well from the people I've talked to Tomcat was dog slow (pun intended). The context I'm talking about is a financial site with very, very heavy HTTP traffic vs. some site dishing out product information with one or two page requests every now and again.

Which is why the WEB team of my former employer went with Caucho's Resin:

http://www.caucho.com/

Open source is great but sometimes commercial solutions are called for... on top of an open source platform of course. (smile)

-Betelgeuse

Re:JSP sites and Tomcat

[Anonymous Coward]

this would depend on which version of Tomcat you're comparing to. If you're talking about tomcat 3.2 or older, there were serious scalability issues. If you're talking about tomcat 4 or higher, the differences are minor. This is from first hand experience. If anything, based on my own benchmarks, tomcat is comparable to resin and orion, which are/were two of the fastest java servlet/ejb containers. resin being an servlet container and orion an ejb container.

the developers deserve credit

[Anonymous Coward]

Tomcat now accounts for a large percentage of the downloads on Apache. In fact, earlier this year the traffic for jakarta related projects was so high, Apache decided all distributions had to be mirrored. Many hours of blood and sweat has gone into tomcat 5. The new features of JSP2.0 like file tags and clarifications on request filters is a good step forward. There have also been a lot of improvements in tomcat. GZip compression is now standard and tomcat 5 includes a plugin feature for Jasper which allows developers to write modules to translate tags to pure java. The new features are worth while.

Tomcat 5 implements JSP 2.0

[Arkham]

One of the biggest changes seems to be support for the JSP 2.0 specification, which incorporates JSTL (Java Standard Template Library) version 1.1. For more info on what this means, read this article at OnJava.com. The Expression Language (EL in the article) adds a lot of nice features to help keep your JSPs clean without having to use struts.

I downloaded Tomcat 5 from an apache mirror, and I am impressed. It was a drop-in replacement for the Tomcat 4 that was included with OSX Panther 10.3.x.

Re:Tomcat 5 implements JSP 2.0

[felipeal]

One of the biggest changes seems to be support for the JSP 2.0 specification, which incorporates JSTL (Java Standard Template Library) version 1.1

Not really: JSP 2.0 incorporates the EL (expression language), which was first introduced at JSTL 1.0, not the JSTL itself.

In fact, it's quite the opposite: JSTL 1.1 requires a JSP 2.0 container, as EL handling is now responsability of the JSP container, not the taglib.

Re:Tomcat 5 implements JSP 2.0

[Anonymous Coward]

In fact, it's quite the opposite: JSTL 1.1 requires a JSP 2.0 container, as EL handling is now responsability of the JSP container, not the taglib.

This is good in my mind, since there were/are numerous developers on taglibs-user and taglibs-dev that asked about how to integrate EL into their own tags. Now that JSP2.0 includes EL, it makes it simple to integrate EL into custom tags. In the past, you had to use the EL in JSTL if you wanted to support script like syntax in custom tags.

the new EL in tomcat 5 is actually commons-el, which is based on the original EL used in JSTL 1.0. EL 1.0 used JavaCC to generate the parser code. The reference implementation team then implemented the remaining classes like resolving variables, and so on.

Re:Tomcat 5 implements JSP 2.0

[shakah]

FWIW, other than as part of a knee-jerk "don't put scriptlets in JSP pages!" dogma, I've never understood why coding advice like the following (from the article at OnJava.com referred to in the parent):

Finally, EL expressions can be mixed with template text directly in the page. This comes in very handy when you're generating HTML elements and need to set an attribute to a dynamic value:

<input name="firstName" value="${customer.firstName}">

With JSP 1.2, you had to use JSTL's action to accomplish the same thing, ending up with a mix of elements of different types that was hard to understand:

<input name="firstName" value="<c:out value="${customer.firstName}"/>" >

is preferred over something like:

<input name="firstName" value="<%=customer.firstName%>">

Re:Tomcat 5 implements JSP 2.0

[fender_rules]

You can always use jakarta-struts to keep your jsp pages simple. It would be instead with Struts.

Re:Tomcat 5 implements JSP 2.0

[Arkham]

I've never understood why coding advice like the following:

<input name="firstName" value="${customer.firstName}">

is preferred over something like:

<input name="firstName" value="<%=customer.firstName%>">

The reason is actually quite simple. The first example, using EL, is syntactically correct HTML. That means you can pass it off to your designer and have them make changes in Dreamweaver or whatever they use. Your example is not valid HTML and will either (a) blow up the tool or (b) overwrite all your JSP tags with valid HTML that breaks your page.

Re:Tomcat 5 implements JSP 2.0

[shakah]

Point taken, but I was wondering more about the benefit of the other example quoted in my original post (which you conveniently elided):

<input name="firstName" value="<c:out value="${customer.firstName}"/>" >

which has little to recommend it over the (IMHO) the cleaner and more-maintainable:

<input name="firstName" value="<%=customer.firstName%>">

Re:Tomcat 5 implements JSP 2.0

[Arkham]

I don't think that either of these examples has significant merit over the other (slight syntactic difference but the same basic concept). I see the big advantage of the EL changes being the need not to use or <%= %> (or any other tag-within-a-tag constructs). The new way is a lot more elegant.

Overhead price?

[Tal Cohen]

I was wondering if anyone knows what's the amount of memory required to run Tomcat (under Linux), when using a simple JSP-base site and when using larger-scale EJB projects?

Re:Overhead price?

[JohnFluxx]

I run tomcat+postgres+kde+eclipse on a 128MB machine, and it just about uses up all the memory.

Deduce what you will from that.

Re:Overhead price?

[baka_boy]

Anyone care to weigh in with an example of their successes (or lack thereof) running an equivalent .NET/Vistual Studio/IIS dev environment on a machine with 128MB of RAM?

Sorry for the dig, but I'm consistently astounded by the gains that all of the major open source Java and desktop tools have made in their efficiency and reliability. I still remember being completely fsck'd by the overhead of green threads with the IBM JDK 1.1.X on a 2.2 kernel whenever I tried to run more than one JVM instance at once...though it was good for building stingy habits w.r.t. runtime object (and esp. thread) allocation.

Re:Overhead price?

[Anonymous Coward]

Linux by default will use as much memory as it can(as any OS would i hope). Running all of those on a 128MB machine means nothing. How much swap do you have and how much is used? If your machine sits there and swaps every time a page is loaded, thats not very good. Imagine your physical RAM as an automobile, and you have to pick up and drop off 20 passengers, but you can only fit 5 people in the car at a time. You will have to swap them in/out and go back for them, figure out the best path, etc. as i said, saying you run all that with only 128MB isn't a very good measure. At work we have a box running apache+tomcat+mysql+a few other things and it uses almost all of its available 384MB plus a little swap.

AXIS

[curtisk]

I've been hunting around the Axis site and Wiki, I guess I can assume (sorry Benny Hill) that Axis should work ok with Tomcat 5.xx? Anyone else try it yet?

And I finally got Apache/Tomcat4.127/Axis working double-plus-good++ :p

Scaling and Model 2/MVC jive

[mactari]

Though the author of the post also defines scaling differently, I believe anyone talking Java scaling versus PHP, etc, should read this /. post in the context of this chapter of Designing Enterprise Applications with the J2EE(tm) Platform, Second Edition that deals with "Web-Tier Application Framework Design", particularly Model-View-Controller ("MVC") style frameworks.

In that paper "Model 1" and "Model 2" set-ups are described in some detail. In short, Model 1 is what most of us web hackers have probably done for years --

1.) A [php/jsp/asp] page for user data entry (data entry GUI) which forwards you to...
2.) Another [php/jsp/asp] for business logic that inserts the jive into an RDBMS, which then forwards you to...
3.) Another page where you might review your data, with links to (1.) or ...
4.) Another page to edit info which links to...
5.) Another page that edits/updates/deletes existing entries and sends you back to 3.)

You get the point. You've got php script or vbscript or Java slapped in between tags that dynamically create pages. That's Model 1.

Model 1 doesn't scale well. It is, however, a great way to get up quickly, and perfect for smaller sites. That's where PHP and dime store hackers find a home, and that ability comprises the "revolution" asp brought to the web.

Model 2 has a controller which tries to abstract as much as possible out of process described above. Check out this image from the Sun chapter mentioned above. See all the steps that go on from each POST from the client interface.

The point of it is that Java/JSP/J2EE allows -- and has the infrastructure as a langauge to support -- this sort of Model 2, MVC interface (As an aside, this is also one of the big advantages of .NET). You can quickly and easily usher these items around in a mature, object-oriented environment. Define an interface and a generic controller and you'll be able to swap around [in theory] fully-QA'd data delivery mechanisms in a modular fashion.

In PHP -- and even asp 3.0 -- this is a more difficult thing to pull off, as mentioned in the /. post I linked to above.

And this is where Tomcat shines -- as a key part of the infrastructure that allows more complex, scalable, generic objects and architectures. Most importantly, since J2EE is a language specification, saying Java scales well is accurate. It provides a true OO platform allowing you to implement Model 2's without jumping through hoops. PHP simply (in my experience) doesn't lend itself to this nearly so straighforwardly.

Now what Tomcat 5 does for me that 4 didn't to achieve this scalability (which many posts have well-documented) is what's most interesting about this story, to which I'll now return. ;^)

Scripting languages and archives

[Kunta Kinte]

How exactly is a language designed to scale well ? In LoC ?

I have a few. One of the bigger design flaws PHP has is the lack of a compiled-archive format.

We have long known scripting languages do not scale well partially because they have to be evaluated entirely at runtime.

PHP's method of archives, ie. include some_library.inc.php is not as rigorous/reliable as import com.example.some_library as the application increases in size in my experience.

I don't know why but, having hundreds of *.inc.php files makes things very difficult to debug. Compared to a large number of packages to import.

PHP should introduce a binary opcode storage format. A standard format that would allow the use of binary archives/modules and runtime opcode caching. Maybe those files would be called .phpc for php compiled or something. These phpc files can seen as the php runtime as compiled independent modules ala .so and Java packages.

Re:Scripting languages and archives

[baka_boy]

Packages, as a namespace boundary separating functional areas of a program, do add a nice chunk of metadata for compilers and debuggers to work with. PHP, by throwing everything into one giant flat namespace, reminds me far too much of C -- in other words, fine if you're dealing with legacy code that uses it, but not exactly where I want to be if I'm trying to be produce quality code.

However, I think that the runtime cost of interpreting a handful of source scripts for each webapp request is really quite minor compared to, say, the cost of opening a connection to a remote service, (RMI/EJB, SQL server, or whatever) marshalling and unmarshalling a series of data structures over that socket connection, generating return text from a template, and all the other work that makes up dynamic web page construction.

Pre-compiled modules are much more important for efficient distribution and deployment of code than they are for its execution. Being able to package an entire application into a single network-transferrable file is by far the most useful contribution of the Servlet container specs -- just drop that WAR file into your apps directory, and off you go.

Reviews anyone?

[aled]

Haven't seen a review of Tomcat 5. Come on, don't make me read that terse changelog that comes with Tomcat. Oh well...

Re:optimizing tomcat

[quinkin]

Well said.

I don't use it, just administrate the servers - but at least now there are some cpu cycles left over...

Q.

Not in apache section?

[cant_get_a_good_nick]

Why is an unrelated slashback entry in the Apache section, yet this didn't make it? Editors, anyone?

Tomcat 5.0.16 + JBoss 3.2.3

[liloldme]

Congratulations to Remy and the team,

For those people looking for the full J2EE stack, the latest JBoss 3.2.3 release also comes bundled with this latest Tomcat 5.0.16 release (The JBoss distro comes bundled with both Tomcat 5.0.16 and Tomcat 4.1.29 service archives). It's a pretty nice combo of two solid servers.

oops... sry, tags are missing in parent post

[fender_rules]

it's
<html:text property="firstName"/>
Should have previewed my post. Sorry :)

Other Servlet 2.4/JSP 2.0 Servers

[rimu guy]

This is good news. Tomcat is the reference Servlet implementation. So if it works on Tomcat it _should_ work on other servlet engines. So people that may have held off deploying or even developing Servlet 2.4/JSP 2.0 application may now start down that trail.

Also, let's not forget there are a couple of other great choices out there: Resin with Servlet 2.4 and JSP 2.0 and the alpha Jetty 5.0 the Servlet 2.4.

Linux VPS Based Java Hosting - Now with Tomcat 5 if you want it

Tomcat 5 & JMX support

[grr34]

Another good news is JMX (Java Management eXtension) support. Untill now, only Bea WebLogic and JBoos (??) have JMX support (not WebSphere) ... Over JMX HP biult a monitoring framework such as OpenView untill now running typically on Bea ...

Eclipse is your memory hog, not Tomcat

[michaelggreer]

Eclipse is a huge app, so we can tell little from you setup. Tomcat mem usage totally depends on your webapp's mem usage. I think tomcat starts in at around 20MB and moves on up from there.