Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Java Programming IT Technology

Tomcat 5.0 Released 44

Posted by Hemos from the pissing-all-over-the-place dept.
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."
This discussion has been archived. No new comments can be posted.

Tomcat 5.0 Released More

Tomcat 5.0 Released

Comments Filter:

  • JSP sites and Tomcat (Score:5, Informative)

    by Trbmxfz ( 728040 ) on Monday December 08, 2003 @08:18AM (#7658909)
    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 [netcraft.com] (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%.
    • 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 (Score:3, Interesting)

      by 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.
      • 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 (Score:4, Informative)

          by antc3 ( 695546 ) on Monday December 08, 2003 @04:22PM (#7662554)

          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.

      • 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 (Score:3, Interesting)

        by zipwow ( 1695 )
        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 [javaperfor...tuning.com] 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

    • Re:JSP sites and Tomcat (Score:4, Insightful)

      by makapuf ( 412290 ) on Monday December 08, 2003 @09:12AM (#7659182)
      > 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.
      • > Java is designed to scale well on big programs

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

      • Scaling and Model 2/MVC jive (Score:5, Insightful)

        by mactari ( 220786 ) <rufwork AT gmail DOT com> on Monday December 08, 2003 @12:30PM (#7660587) Homepage
        Though the author of the post also defines scaling differently, I believe anyone talking Java scaling versus PHP, etc, should read this /. post [slashdot.org] in the context of this chapter of Designing Enterprise Applications with the J2EE(tm) Platform, Second Edition [sun.com] 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 [sun.com] 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. ;^)
      • 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 Everythin

      • 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.
      • 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/accountin

      • Re:JSP sites and Tomcat (Score:2, Interesting)

        by hlee ( 518174 )
        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).

      • 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.ph

        • Re:Scripting languages and archives (Score:4, Interesting)

          by baka_boy ( 171146 ) <lennon@@@day-reynolds...com> on Monday December 08, 2003 @03:59PM (#7662333) Homepage
          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.
    • 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

  • the developers deserve credit (Score:5, Informative)

    by Anonymous Coward on Monday December 08, 2003 @09:43AM (#7659378)
    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 (Score:5, Informative)

    by Arkham ( 10779 ) on Monday December 08, 2003 @10:25AM (#7659653)
    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 [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 (Score:5, Informative)

      by felipeal ( 177452 ) on Monday December 08, 2003 @11:51AM (#7660281) Homepage
      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.
    • 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

      • You can always use jakarta-struts to keep your jsp pages simple. It would be instead with Struts.
      • 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 too

        • 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%>">
          • 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 <c:out > or <%= %> (or any other tag-within-a-tag constructs). The new way is a lot more elegant.
  • Comment removed based on user account deletion
    • 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.
      • 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...

      • Re:Overhead price? (Score:1, Informative)

        by 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
      • 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.
  • 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

  • Haven't seen a review of Tomcat 5. Come on, don't make me read that terse changelog that comes with Tomcat. Oh well...
  • 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 (Score:5, Informative)

    by liloldme ( 593606 ) on Monday December 08, 2003 @08:27PM (#7664750)
    Congratulations to Remy and the team,

    For those people looking for the full J2EE stack, the latest JBoss 3.2.3 [sourceforge.net] 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.

  • Other Servlet 2.4/JSP 2.0 Servers (Score:5, Informative)

    by rimu guy ( 665008 ) on Tuesday December 09, 2003 @01:26AM (#7666312) Homepage

    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 [caucho.com] and the alpha Jetty 5.0 the Servlet 2.4 [mortbay.com].

    Linux VPS Based Java Hosting - Now with Tomcat 5 if you want it [rimuhosting.com]

  • Tomcat 5 & JMX support (Score:2, Informative)

    by grr34 ( 651335 )
    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 ...

Slashdot Top Deals

"Hello again, Peabody here..." -- Mister Peabody

Close