Slashdot Mirror
Apache Tomcat 4.0 Final Released
A reader writes "The latest version of the Apache Java Servlet engine has been released. 'The 4.0 release implements the Servlet 2.3 and JSP 1.2 specifications.' Read more at The Apache Group's Jakarta site."
← Back to Stories (view on slashdot.org)
Tomcat is getting pretty good. Version 4 makes it very easy to deploy new webapps: it includes a web admin interface, and new apps can be deployed without restarting it. As a standalone webserver it is also fairly competent, at least for specialised applications with smaller user numbers.
.NET. Actually I think it is ahead. In the future we will get the XML Binding API, that makes it possible to compile XML Schemas to java "xml manipulator" classes that can be used to manipulate XML instances of these schemas. XML parsing and manipulation will then be childs play. Define your schema, compile it and you have code that is specialised to work with these documents!
Apache does some great things with Java. I have worked both with Tomcat (servlet container), Xerces (XML parser) and Xalan (XSLT engine). Thanks to the good work to come out from Apache, Java has become a very strong competitor to MS
With a strong XML foundation in place, Java's future is looking really good.
I'm not completely up to speed on what Java Web development enhancements this brings to the table. However, I can honestly say that in my dealings with ßeta versions of Tomcat 4.0, the configuration files for Tomcat 4.0 are 1000x times easier and more sensible! The configuration files for Tomcat 3.x look like they were designed by a monkey on crack (or a Sendmail developer). Tomcat 4.0 config files are finally well thought out and usable. Can't wait to get my systems upgraded! :)
Tomcat 4 was waiting for the new servlet standrd from Sun to become from draft to final.
:)
THAT WAS TODAY. Less than six hours later (I don't know the exact amount of time) Tomcat was announcing the official release of Tomcat 4. That is going fast!
That the 2.3 Servlet specification and 1.2 JSP Specification have been released as final.
Marcelo Vanzin
Anybody else appreciate the irony that 4.0 Final is released while 3.3 is still in beta?
I've been using Tomcat 3.2 in production for the last 6 months or so and it's been a wonderful servlet container. I can't wait to try out 4 in our testing environment!
You can accomplish anything you set your mind to. The impossible just takes a little longer.
Make sure you have a JDK installed, like Sun's Windows version.
Unzip to a directory - taking the defaults sets you up in c:\jakarta-tomcat-4.0.
Go to the control pannel, click system, click advanced, click Environment Variables. Click new button on system variables and create a JAVA_HOME with a path to where you extracted your JDK. (My box has javac located in c:\jdk\bin, so my JAVA_HOME is c:\jdk). Create a TOMCAT_HOME as above pointing to c:\jakarta-tomcat-4.0.
Open up a command prompt, cd to c:\jakarta-tomcat-4.0\bin and run startup.bat.
Open a browser and type in http://localhost:8080, you should see it...
Happy hacking in the example code!
+++ UGUCAUCGUAUUUCU
Does Tomcat4.0 support load balancing the way 3.2.x did?
In 3.3.x you could load balance a cluster of Tomcats through apache and mod_jserv or mod_jk (which is what we use). So does T4.0 support load balancing and if so is it through mod_jk or is there a new module to do the job? If so has anyone played with it yet?
Your pizza just the way you ought to have it.
I wasted a week of my life trying to get tomcat 3.2.x up and going on a solaris machine. The documentation was the worst that I had *ever* run across, with "how-tos" sporadically jumping back and forth between version 3.1 and 3.3, with not one single "clear, concise, consistent" document available for 3.2 (the previously current stable version). Even step involved downloading another package from the jakarta project, trying to figure out *it's* documentation, installing it, testing, and then finally getting back to tomcat just to discover (generally buried in some obscure comment four pages into a mostly-irrelevant faq) that you need to go get something else.
.jsp support in all my user's home directories, the same way we do with cgi's (this is intranet, and we have a lot of people running things out of their ~username). Can't be done. Absa-no-freaking way. Either you configure each directory individually, basically "giving" the /public_html/ dir to tomcat and bypassing apache completely, or you make everybody create a new directory and then configure them *individually*. If someone has a work around for this, I would *love* to hear it. Note the main problem is that tomcat doesn't understand the ~ syntax, so the url passed by apache when a .jsp page is requested is "foo.com/~user/baz.jsp", and then tomcat complains that ~user/baz.jsp doesn't exist. This is the #1 reason jsp/servlets aren't used more where I work.
Frankly, it wasn't until I got it going on a debian/x86 machine (apt-get install tomcat) that I was able to trace my way back and install it on solaris. Not that apache itself was much better, trying to get apxs working.
Then, after it was going, I tried to enable
So, I am *eager* to try out this release, and I truly hope that my complaints are now foundless. I would love nothing better than to be proven wrong, that the documentation has been completely overhauled, that it now understands the common ~username, that it works with any jdk besides blackdown's (on linux), and that it basically doesn't suck. But I'm not holding my breath.
I'm currently working on a certificate authority written with servlets (and JNI calls to libopenssl for the gory work of actually creating and signing the X.509 certs), and everything is using EJB beans. The goal is to have the CA entity beans handle the actual CA and X.509 tasks, another set of beans and JSP to handle the web and java client interfaces, and yet another set of beans to handle the business rules regarding content and issuance of the certs, and tying it all together with J2EE or something similar.
The only problem is that I seem to be missing a piece of the puzzle. For now, I'm creating and initializing the beans explicitly, but shouldn't this be handled automatically somewhere/somehow? I'm sure I'm just missing some small piece of information in this huge pile. Does this release address this problem, or is it an entirely different set of code?
(As a related aside, I'm gonna stop using Debian if it continues to have such long release cycles. I eventually got suitable openssl (0.9.6), postgres (7.0) and java (1.3) installed, but it took days and a lot of pain because of the length of the "to do A you must first do B, to do B you must first do C, to do... chain.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
This project seems that it could fill the role of a great that that Sun wanted to accomplish with Java. The versatility of Servlets is quite extensive and it makes me wonder why, in the shadow of this project, the OSS community is spending time on dotGNU and Mono.
.NET wants to. And, it's not restricted to Windows.
.NET killer out of this, or am I thinking about driving a screw with a hammer?
Tomcat has tremendous potential to deliver robust, complete apps in the same way
Is my thinking correct in that we can level this software against Microsoft's upcoming ventures? Can we make a
Why bother.
also ant 1.4 was released recently (couple weeks ago). ant is a great build tool, i don't want to get into its features here (java and xml based build, replaces makefiles for my java builds, integrates with some IDEs and build verification/unit test tools (JUnit)). the reason i post here is because ant started out as a little tool with which tomcat developers build tomcat, and grew into its own tool. ant home page on jakarta.
The REAL sam_at_caveman_dot_org is user ID 13833.
Can someone speak to us lay-people (when it comes to Java anyway) about the differences between Tomcat and J-Run? Are the competitors? Do they fit different niches?
I'm just wondering because I know some folks who are looking at upgrading J-Run, and I might advise them to check out Tomcat instead if that makes sense.
Thanks!
Not trying to indulge in a religious war, but I'm curious as to why PHP is so popular when JSP provides a much more robust solution. IMO, JavaScript is a real language compared to PHP's half-hearted C-like syntax, and it implements a real object model, again unlike PHP. I'm also uncomfortable with Zend's pricing scheme for their optimizer, whereas I can choose to use a JVM with JIT when using JSP at no cost. I also don't need to worry about proprietary caching schemes.
Any word on whether they support IIS integration like the 3.x line did (via mod_isapi.dll, which hooked into the ajp12 connector)? It was fantastic, and helped bridge my application while it was being rewritten into Java-only.
I can't seem to find any docs on how this might work, nor could I find any information on ajp12 at all in the 4.0 documentation! Now that the app has been rewritten (completely, finally) away from VB/asp to Java, it is possible to move to Apache (on any platform, since the code was carefully written to avoid platform-specific issues), but I'd still like to have the option of sticking with IIS at least for testing/benchmark comparison purposes...
You can accomplish anything you set your mind to. The impossible just takes a little longer.
I dunno, Tomcat's configuration is horrible and I couldn't get it to run as a service on Windows, which is worthless. JRun has a very simple configuration interface, works well, and doesn't require editing of cryptic text files. They also have a free version available for development.
IMO, Simplicity isn't necessarily a bad thing...
Web server and tester on the same machine? What? Were you same the one reponsible for the Mindcraft benchmarks as well?
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
If not, why not? Why aren't there more OS projects that target these kinds of mission critical applications that the enterprise needs? It strikes me that if you want these kinds of capabilities from OS software, you are basically left to building them from scratch on top of something like JBoss/Tomcat, Enhydra, etc. Unless I'm missing something, there just doesn't seem to be any OS applications targeted at these important enterprise capabilities.
-Vercingetorix
"Necessitas non habet legem." -St. Augustine
Actually, I find the 4.0 documentation to be much better than previous versions. It also has very good quality in general when you compare it to 99% of other open source projects out there, not to mention some commercial products. You should check out their how-to's, you'll see what I'm talking about.
"The deluded are always filled with absolutes. The rest of us have to live with ambiguity." - Aristoi, Walter Jon Willia
gnujsp)and Tomcat, but man, talk about night and day difference in installation headaches.
Quite frankly, I've yet to make Tomcat work completely right. Installing new servlets and writing JSPs was pretty easy under the old system, and the integration with Apache was pretty good, so you may be able to implement ~username servlet and JSPs using that system instead. (Unless you need something in the later specs.)
(I'm fooling with tomcat 4 on a win2k machine at the moment and it does look pretty smooth, but then I've only had about 15 minutes yet to mess with it.)
News for Geeks in Austin, TX
You raise good points but I think that a certain extent you're missing the point of the whole alphabet soup of Java web development (Servlets/JSPs/Beans/J2EE/JDBC/MBeans/EJBeans/JXTA /JMQ/"und blah und blah und blah" [ObLola]).
Java [stuff] is intended to fit a monolithic development environment, where you have one application, no, make that Application, you're working on, with a team of highly (or at least somewhat) trained fellow coders wearing pinstripe suits likely on the behest of people that also wear pinstripe suits who probably do boring things like investment banking. The project manager has read The Mythical Man Month, and you all work in very formalized and well defined roles. The s(w)ervers are yours and yours alone to utilize to develop and deploy on.
Contrast this with ISPs, smaller web shops, and individual coders. They usually work in small teams, on short projects of small scale, and on machines that are shared with a lot of people. So simplicity and resource utilization take priority over Absolute Completeness And Verifiable Correctness.
Given that, it's natural for PHP to flourish where it does, and for Java [stuff] to flourish where it in turn does. Once again, right tool, right job.
(Lest anyone think I'm flaming, I like both environments, for different reasons and in different places.)
News for Geeks in Austin, TX
Can someone tell me what is it that Tomcat 4.0 (or any other version) lets me do that cannot be done otherwise? I know there must be something for them to put all this effort into it, but I cannot see it. If you're tempted to say "well if you can't see it, you won't understand it" then I'll say you probably don't understand it for yourself and you're doing it for the fad value of it.
I want to know what the advantage is over say:
now we need to go OSS in diesel cars
We actually find it quite useful to get around some of the problems with Java embedded in web pages.
You don't need them per say. But a lot server-side applications are written as servlets.
What is the advantage of doing a servlet? Just to be programming in Java?
Yes, but I don't think that really answers the question you're asking. A "servlet" is just the affectionate term for a server-side Java application. "Servlet" implies Java the same way "applet" does.
You can write server-side applications in any of these languages, they're just not called servlets.
So what does Tomcat have to do with this? If I write in Java and compile it to a host machine executeable binary format instead of a class file, and run it under the CGI mechanism, would it still be called a servlet?
now we need to go OSS in diesel cars
So why can't I just compile my code after I write it, and run it that way?
You can.
And why do I have to mix code and content?
This is a difficult question. You don't have to mix code and content. In fact you want to do so as little as possible. Here's what it comes down to:
Many large scale web sites are a combination of front end UI written in HTML/CSS and backend database-driven functionality written in Java. Somehow you need to dynamically generate HTML based on database content and given critera. People figured out pretty fast that most web pages are sufficiently complex that embedding HTML/CSS directly in Java code (or a Perl/CGI script) is not a good solution. It makes the Java code difficult to read for the programmer, and it makes it very difficult for the designer to change the appearance of the site.
Things like JSP and PHP attempt to head towards solving this. Rather than having all the HTML and Java code in one massive file, you have more template-like functionality. You initially create a HTML page as your template, then add dynamic elements using the scripting language. With JSP, the bulk of functionality is theoretically stored in other places, like JavaBeans. You then call this functionality with custom tags.
This is not enforced, however. PHP and JSP are quite rich languages. If you design or maintain your JSP/PHP application poorly, you might find yourself back at square one: too much mixing of code and content. Except this time, too much code has creeped into the content, rather than the content creeping into the code. I must emphasize that it doesn't have to be this way. At least in the context of PHP, proper use of includes and objects should solve most major problems. But not everybody is that careful.
Another (some would say more evolved) approach are the pure template languages like Velocity (for Java) and Smarty (for PHP). They do not have the rich language structure of raw PHP or JSP. They only provide the most basic ways to output data. They force you to put complex logic somewhere other than the HTML template.
For the most demanding enterprise-class applications, you will need a full scale application server with load balancing, enterprise frameworks, and other high-end featurees. One such app server is WebObjects. There are many others.
You're talking about some good things, but I'm still looking for why Tomcat is the only, or best, way to have this.
It's definitely not the only one, and the best is certainly a matter of what you're trying to accomplish. There are a lot of options out there, and it's understandable that you might be a little overwhelmed.
The first thing to do is determine what your needs are. A lot of people like PHP, and with good reason. It's fast, it's easy to learn, has a lot of very useful built-in functionality, and is open source. PHP can also interface with Java. However, it can be argued that PHP cannot provide the infrastructure and scalability that a pure Java solution can.
If you decided to use Java, you have a mind-boggling number of options open to you. The options range from free/open source to very expensive. You have servlets, JSP, Velocity, Cocoon, XML, application servers and much more. Java has hooks into just about every aspect of server-side application development right now. To choose one as the best is impossible. It might make things to think of Java as the platform for all of these things.
Tomcat, specifially, is a servlet/JSP engine. There are dozens of other such pieces of software. Tomcat tends to get more visibility because it is under the Apache banner.
So when deciding what to use depends on these varibles, in addition to others:
[1] Your timeline to complete your project
[2] Your existing programming knowledge
[3] Your budget/human resources
[4] Sophistication of the site/application you need to build
[5] Personal taste
There is no one perfect solution for everyone, but some are more popular than others. In your case, you probably want to choose something with broad community support and lots of free documentation, sample code, third party books, etc. In my personal opinion, if you're just getting started with web development, and have absolutely no idea what you want, try PHP. It will probably get you up and running the quickest. It also has a tendency to teach you web development concepts without you realizing it.
If you want to get more involved in web development as a career, you might also want to get a book that teaches you the Java language (ideally, with a focus on servlets). After that, you might have a clearer idea of what to tackle next.
- Scott
Scott Stevenson
Tree House Ideas
What is the advantage of doing a servlet? Just to be programming in Java?
:)
A server-side Java application is called a servlet. It has no special status that I'm aware of.
So what does Tomcat have to do with this?
Tomcat provides you with a means to use servlets and JSP on your web site.
If I write in Java and compile it to a host machine executeable binary format instead of a class file, and run it under the CGI mechanism, would it still be called a servlet?
No, I don't believe so. I think they are only refered to as servlets if they exist as Java bytecode. But I'm not sure why you'd want to do what you describe here.
- Scott
Scott Stevenson
Tree House Ideas
I think they are only refered to as servlets if they exist as Java bytecode. But I'm not sure why you'd want to do what you describe here. :)
Actually my goal is more to do template logic elements as modules dynamically loaded and called in the same process, as briefly described here.
now we need to go OSS in diesel cars
but I'm curious as to why PHP is so popular when JSP provides a much more robust solution
PHP is not a one-fits-all type of solution. It does not provide the same infrastructure that Java solutions do, and it is not a pure OO language. However, there are some good reasons to use it, depending on your situation:
[1] Easier to learn than Java
[2] Simpler to setup than many Java solutions
[3] A great selection of extremely useful, easily accessible, built-in functions
[4] Wide selection of books that don't assume you're already an experienced engineer
The creators of PHP went to great lengths to remove as many of the needless annoyances of web development as possible. They provide a lot of ready made solutions to small, but annoying common problems. The language has bent itself to developer needs, rather than the other way around.
PHP's creators realize that people just want the damn thing work, which is even evident in the installation instructions and documentation. This philopsophy, while starlingly rare in the open source world, is probably at the core of why PHP has such a devoted following.
The strip_tags function is probably a good example of this. You give it a text string and it will remove all HTML tags contained therein. That's it. You can optionally tell it specific tags that you would like to leave in. This function is built into the language. PHP users love this. Many other languages would expect you to write a custom regex routine or go find some code somewhere to take care of it. Or you can start playing the module dependency game. These isn't the kind of stuff I want to do at 2am.
- Scott
Scott Stevenson
Tree House Ideas
That's *one* licence it grants. The JRE *also* grants you the licence to use it in a normal way. This really isn't a problem - people have been distributing the JRE with their apps for ages.
Jon
Where better to start than Sun's own tutorial?
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
Yet another non-Java developer trashing JSP's.
I'll agree with you -- for pounding out web pages, it is much easier to do it in perl or php. But if that's all you want, then even perl and php are overkill. Why not just write static HTML pages?
JSP is useful when you need to talk to Java components to get real work done. If you are a web designer, then don't use it. But if you are working on a big project, then the web interface is probably the least important part of the whole thing. Java provides a much richer set of tools than perl or php for creating reusable business components, and JSP provides an easy way to stick a front end on top of that.
JSP scales a lot better than PHP/perl for mulitple developers, too. It sounds like you are more of a web designer than a programmer. JSP might make you feel unconfortable, because you wouldn't get to program as much, but the lines of responsibility are more clearly drawn. The guys in charge of the business beans would make up tags for you to use, and you could work on making the screens look pretty in Dreamweaver.
So what can you do with JSP that you can't do with PHP, Perl, ASP, etc? Talk to Java. That's what we want to do.
If you want to talk to a perl module, then use mod_perl or HTML::Mason. If you have COM objects, then use ASP.
JSP is just a front end! The decision has already been made, long ago, to go with Java for all of its obvious business programming advantages.
-Mike
JSP has not exactly taken off like wildfire - the largish Java language, and the relative complexity of its runtime environment means JSP can never hope to catch PHP in terms of development and execution time for 99% of web publishing tasks.
Use the right tool for the job.
No. Nor would it run correctly. Servlets depend on several things exposed to them by the Servlet Container. Security sandbox, the ServletContext (a ton of config variables and methods useful for servlets) and other things. It is the servlet container which does the most basic processing of requests, then passing them on down to the servlet, usually. If you really want to know about it, buy a copy of Java Server Programming.
-
The problem is not the nature of dynamic scripting languages (which I take to mean languages that let you prototype quickly). The problem is design choices made in the particular languages you've looked at. BRL has no problem scaling to more complex applications. And if you choose to prototype quickly and end up with "dirty" code in pages, cleaning it out is a mindless process, as I described in another comment.
Actually, I looked at 3 or 4 such books in a bookstore a couple months ago. My impression was that JSP was horrendously complex, and IMHO needlessly so. I felt all that configuration and detail pur performance at risk, as well as administrative sanity. JSP definitely does not follow the KISS principle. It seems to go out of its way to avoid it.
You might want to explain the benefit of all those config variables, for I don't see it.
now we need to go OSS in diesel cars
Aside from standard CGI variables, theres logging methods, as well as it includes any custom config options you've specified in the configuration that only pertain to your servlet.
Truly, if you havent bothered to try to learn it, dont bitch about it. That's just silly.
-
FWIW, I found ASP to be horrendously complex, too.
As far as learning it before bitching... you're misinterpreted what I'm doing. People say this stuff is specifically good and point to the whole thing, then say it is good because of one part of it. For example, the argument goes that one should do their web site in Java. But that suggests that all the benefit is from the Java language. What they really mean to say is that choosing Java and all that comes with it, including the API, JSP, and implementations like Tomcat and Velocity, are the benefit. What I'm trying to get pinned down is exactly what parts contribute what benefit, and identify what parts can be plugged in elsewhere. And also to pin down where the synergy between the parts exists. I want to determine, for example, if the Java language is better than the C++ language (or Perl, or PHP, or C) because of all that comes with it, as opposed to the language itself.
BTW, the idea of requiring someone to learn everything before being eligible to criticize it (which I don't feel I'm doing, yet ... I'm really trying to isolate what could be of benefit even if it were separated from the other stuff) is a cop-out. Have you really learned C ... I mean really learned it, including all the APIs that everyone has developed to make it much more powerful than even K&R could imagine? Have you really learned all the Perl modules out there? And have you learned everything in all the Java APIs?
What you're asking is not practical. No one can learn it all. And choices have to be made well before one has a chance to learn it. One has to choose what to learn and they have to determine what is best for them to make that choice wisely. I think that those who do learn all about one thing and understand it well should be able to explain it clearly to someone who has not learned it all, so that they may make the wise judgement whether it is something they ought to pursue learning. In my case, I want to know why all the environment that surrounds Java (not the language itself, or even its basic API) is something I should pursue. Someone telling me it worked out great for them is not telling me it will work out great for me.
now we need to go OSS in diesel cars
So the persistence is for the purpose of avoiding startup costs, as opposed to having session state ready without having to access a database? I'm a bit surprised that performance and cost are considered so important. But maybe they are thinking, or hoping, that Java will soon achieve C speeds. I know I'd like to have that, which is why I am looking forward to development in areas like GCJ that can let me compile directly to my host instruction set.
Yeah, there was "FastCGI". I tried it, but found it to be too full of problems. Personally I'd rather use C for things that need a lot of CPU performance (for example generating images dynamically) or Java for complex logic that doesn't really demand a whole lot of CPU time. C for the grunt work and Java for the think work. Does that make sense?
BTW, one of the things I'm considering doing in the design I'm working on is session persistence. That is, a process will persist for some time after each request, and when a new request comes in, the first thing the engine does is find the process for the session indicated by the cookie or wherever the session ID is passed, and pass the connection to it (perhaps to be implemented with named pipes and socket file descriptor passing). This process would then "resume" to handle the new request as a continuation of the session. The session state would still be in the variables that process holds. It would then save it's state somewhere at some time after the last request and could exit any time after that.
now we need to go OSS in diesel cars