Apache Tomcat 4.0 Final Released 288
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."
Tomcat looks good (Score:5, Informative)
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.
Re:Tomcat looks good (Score:1)
Java has strong infrastructural strengths already (and have had so since day 1).
OTOH, once
that supports any MS programming language (and more!) of your choice
Re:Tomcat looks good (Score:2, Funny)
Yes, but will
Re:Tomcat looks good (Score:3, Funny)
"We're doing this because our customers and the public ask for it. This way, our software can help them avoid hassles associated with incompatibilities among programs." An anonymous spokesbeing says.
Re:Tomcat looks good (Score:1)
very cool (Score:5, Informative)
Re:very cool (Score:1)
Come on, let's give the Tomcat programmers a little credit. 3.x config files are nowhere near as bad as sendmail.cf, they're just a little verbose.
Woah! (Score:1)
Re:Woah! (Score:1)
Still, please try it out. Tomcat rocks! Many thanks to Craig, Remy, and the other developers who made Catalina a reality.
Mike
Good places to start? (Score:1)
Re:Good places to start? (Score:1)
Apart from all the updates that have been made to the architecture, the ability to update servlets without having to restart the server will be VERY nice.
I also hope that the MySQL JDBC support is quickly updated to allow for the more powerful DB operations that the new specs support, that would have made my life easier last summer.
Re:Good places to start? (Score:2)
Where better to start than Sun's own tutorial [sun.com]?
WOW - 6 hours (Score:2, Informative)
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!
Re:WOW - 6 hours (Score:2)
And that also means... (Score:2, Informative)
Hehe (Score:3, Insightful)
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!
Re:Hehe (Score:3, Informative)
4.x has been in beta for a while, they've mainly been waiting for Sun to finalize the specs.
Re:Hehe (Score:3, Informative)
and development while the 4.x tree gets shaken out.
I know. Actually, 3.x was based on the Sun Java Server, whose source code was donated.
The irony is that it's taking longer for the 3.x line to get fixed properly than it is for the developers to have worked from scratch on a rewrite of the whole thing. There are quite a few things wrong with 3.2 which I won't get into (yes, we DO use it in production). I know that these things have been addressed in 4.0, while 3.3 is still working on it.
Very Mini howto... (Score:5, Informative)
Make sure you have a JDK installed, like Sun's Windows version [sun.com].
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!
Re:Very Mini howto... (Score:1)
...
Unzip to a directory - taking the defaults sets you up in c:\jakarta-tomcat-4.0.
Call me crazy, but I dont think my linux box will like that too much
Re:Very Mini howto... (Score:1)
Just "cd c:\\jakarta", but about that startup.bat, how am I supposed to run that thing
Re:Very Mini howto... (Score:3, Informative)
Create a TOMCAT_HOME as above pointing to c:\jakarta-tomcat-4.0
This should actually be CATALINA_HOME. The TOMCAT_HOME var was in the older versions.
The RUNNING.txt file included in the distributions contains the installation steps and, yes, they are very simple.
Re:Very Mini howto... (Score:1)
Without reading the docs (grin), I think that had more to do with setting up just the servlets. Could be wrong, won't be the last time...
Load balancing? (Score:2)
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?
Hopefully it intalls easier... (Score:3, Informative)
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.
Re:Hopefully it intalls easier... (Score:2)
Re:Hopefully it intalls easier... (Score:2)
Re:Hopefully it intalls easier... (Score:2)
Maybe you could write a script that did the configs for you?
yeah, tomcat 3.x is a train wreck (Score:2)
gnujsp [klomp.org])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.)
J2EE-ish support? (for java CA) (Score:3, Interesting)
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.)
Re:J2EE-ish support? (for java CA) (Score:2, Informative)
LEXX
Re:J2EE-ish support? (for java CA) (Score:1)
Re:J2EE-ish support? (for java CA) (Score:2)
To be fair (since many non-developers read this list), this release cycle has been particularly nasty because some key Debian tools now depend on Perl 5.5, and that forces you to fully convert to 'unstable' instead of installing a handful of selected packages. (Some maintainers archived the last pre-5.5 version in 'pool', but many did not.) But by that same measure the release manager should have identified introduction of Perl 5.5 and the tools as the trigger for the next release since it's a *huge* roadblock to this type of "stable + one or two updated packages" approach that many of us prefer.
Re:J2EE-ish support? (for java CA) (Score:1)
Re:J2EE-ish support? (for java CA) (Score:2, Informative)
Tomcat is a servlet container, not an EJB container. As such, it can only run servlets, jsp's (which really are just special cases of servlets), and javabeans. You need an EJB container to run EJB's. The most popular open-source EJB container is JBoss [jboss.org] (it also integrates very well with Tomcat).
Your are correct in saying that you never instantiate an EJB directly, you ask the container for a reference to an EJB and the container can instantiate a new EJB for you or reuse an old one or pull one out of a pre-existing pool.
BTW, you may want to look into using JAAS (Java Authentication and Authorization Services) which was released today as a component of J2EE 1.3 for some of your security needs.
Re:J2EE-ish support? (for java CA) (Score:2)
Tomcat As the Anti.NET? (Score:4, Interesting)
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
Re:Tomcat As the Anti.NET? (Score:2)
Tomcat is great if web pages are your goal.
It's not a J2EE complient system, you have to use something like JBoss with it to do that.
Also, what does tomcat do to help my php/python/perl and (yes) windows software? Not much unless I integrate into it XMLRPC or SOAP which is not trivial.
I don't believe that J2EE is very accessable unless your using a java client, again if there are solutions out there, they are hardly well accepted or trivial to impliment (unlike XMLRPC for example) I suppose.
Re:Tomcat As the Anti.NET? (Score:3, Insightful)
Point by point here, how does Java suck? Java is a great language for all kinds of tasks. The extensive API already available for it is a big plus, and it is, for all intents and purposes, truly cross-platform.
Java is not as slow as most people claim. Like any programming language, performance is dependent largely on the programmer. A lot of programmers with poor skills use Java because they can focus on their tasks instead of building the tools to do said task. Here's an article [slashdot.org] on
Sun has done a lot of good for the OSS community. If you'll notice OpenOffice, and well, Java is a great piece of code for the Linux world. I'd say that Sun != Microsoft. Get a clue.
Re:Tomcat As the Anti.NET? (Score:2)
You can bet that IBM's lawyers have done the worrying for you.....
slightly offtopic, other jakarta stuff (Score:3, Informative)
J-Run (Score:2)
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!
Re:J-Run (Score:1)
Does that answer your question?
Re:J-Run (Score:1)
JRun Enterprise also has an EJB container, which would be comparable to JBoss w/ Tomcat integrated.
All other versions of JRun would be direct competitors to Tomcat.
Re:J-Run (Score:3, Informative)
JRun is commercial, from Allaire/Macromedia. You can download it for free, though, at Allaire [allaire.com]. They have several different versions to download. Professional and Enterprise are the full version of the product, but with a 30-day time limit. You'll need a license key. The difference between them is that Enterprise supports EJB, JTA, and JMS, which are Java API's for building complex applications on the server. Tomcat is like Professional in that it supports JSP and servlets, which are similar to PHP and CGI Perl for all you non-java slashdotters.
I actually don't have performance numbers for Tomcat 4.0 and JRun 3.1, since Catalina just got GA'd. If you can live without the support for JRun from Macromedia, and you want to save about a thousand bucks a server, give Tomcat a chance. You're probably not using EJB (Enterprise JavaBeans) anyway, since they were only supported in JRun 3.x.
Re:J-Run (Score:3, Informative)
Why use PHP? (Score:2, Interesting)
Re:Why use PHP? (Score:2)
Re:Why use PHP? (Score:2)
Let's not forget that there are alternatives to JSP which might be even better to work with. I would strongly encourage you to check out Velocity [apache.org].
Don't want to get into a religious war about this one, but I can say that when I was evaluating my company's Enterprise solution a few months ago, Velocity seemed to be more flexible and offered a better way to separate design from code. JSP suffers from the same things that haunt developers using ASP - it's much too easy to end up with dirty (extremely dirty) code after a few rounds of maintenance.
Re:Why use PHP? (Score:2, Informative)
Gollo.
Re:Why use PHP? (Score:2)
My favourite parts of Velocity (and Webmacro, which inspired Velocity), and likely the other template engines, is that unlike with JSP I can use it to produce virtually anything I want. For example, currently I use Velocity templates on my production server to generate web pages, XML (for data transfer to customers and/or partners) and email notifications (by pumping the generated text out into whatever OutputStream I want, I can send it anywhere). When changes are needed, it's easy to implement, and often just a quick job in notepad does the trick. Plus, auto-reloading of templates is a huge bonus for me - Tomcat's automatic servlet reloading didn't work, but being able to change my templates on the fly has helped me a great deal when handling issues with our production box.
On the negative side, I didn't like Velocity's default configuration, which I found confusing when dealing with defined Macros (all macros you create in any template are declared in a global namespace by default, for example). This can be changed, however, by carefully reading the docs and writing your own configuration file.
I'm not familiar with Tea or FreeMarker, but I imagine they have similar capabilities.
Re:Why use PHP? (Score:1)
JSPs rock. Javascript is often useful but can be a PITA because you can never really trust client-side technologies.
Re:Why use PHP? (Score:1)
JSPs can use server-side Javascript (Score:2)
We actually find it quite useful to get around some of the problems with Java embedded in web pages.
Re:Why use PHP? (Score:2, Informative)
For $10/mo, I get PHP/MySQL, unlimited bandwith, unlimited hard drive space, unlimited POPs, etc.
Plus there's cool stuff like PHPNuke, just getting a simple contact me mail-to form to work in PHP is a piece of cake.
Oh and a small correction - JavaScript has nothing to do with JSP or Java programming at all.
Re:Why use PHP? (Score:1)
Re:Why use PHP? (Score:5, Informative)
good points, but... (Score:2)
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.)
Re:good points, but... (Score:2)
From what I've read, and in searching for an inexpensive webhost that supports JSP / servlets, it doesn't fit in well in a shared hosting environment. However, there are a few that make it work. Again, contrast that to PHP, it makes server stuff easy in a web hosting environment.
And as for what I like, well, my weblog thing is managed by a big ugly (but very useful) Perl script, my link archive is PHP, the shopping cart I'm setting up is PHP / MySQL. But the reading and 'playing' to learn and the fascination is with servlets / JSP / other Java solutions.
Re:good points, but... (Score:2)
Better speed, too.
Re:good points, but... (Score:2)
<flameshields>
People who program in VB are not real programmers.
</flameshields>
Now if they are switching over to Java, they may really be learning to program for real. But be careful. The easier some language is supposed to make things, the more likely it is that those who don't so so well will be able to at least do something. Thus the IQ level of programmers who use UltraEZlang++ are likely to be lower than TuffLuvLang--. The question is, which is VB and which is Java? And are these new Java converts going to end up switching again to something where they end up cutting cut on the sharp edges?
Re:Why use PHP? (Score:2)
Perl & PHP are (imho) closer to the systm. I am currently writing an asset managment system that tracks and organizes various files as well as performing various operations on those files.
All of our main application servers are running on Java (Resin, not Tomcat though
For the project I have on my radar, I don't know if JAVA will let me take advantage of all the native unix command line tools that are out there. I don't know how other programmers feel about taking advantage of chaining unix tools from within programs using things like system forks, etc., but it has helped me write very robust code and impliment it in a way that puts solutions out the door fast.
Unfortunately the problem I have with Java (it's getting better.. ), is when there is any threading in the picture, things go fast until things get VERY concurrent with lots of users. Maybe I am not a good enough programmer to overcome some of these problems, (I have only been programming professionaly for about 4 1/2 years, 2 of which exclusively with Java and previous in C/C++/Perl). I have had situations where I have gotten myself into trouble with unmaintainable code with PHP, I think most beginner PHP programmers do, but I am not making that mystake now.
The nice thing about technologies such as XMLRPC / SOAP
PHP can be a very valuable tool because it illiminates a lot of the details that frankly, most people like myself just get themselves into trouble with. One other point, I have never gotten myself into a performance hole with PHP, Java I have. I have learned from those mistakes of course and probably wouldn't have any problems with performance if our team had the chance to rewrite all the java from scratch, hindsight is 20/20.. but I guess that is what experience brings you.
Maybe when I am 10 years old and have a few more hairs on my chin, I will be able to pickup any language and not dig myself into a pit.
Experiment with all the environments, you will find what suits you best... I personally am still waiting for a viable alternative to Zope as Python is my language of choice.. I am still waiting for PHP to impliment Exceptions so I can write better error trapping, and I am STILL trying to hone my skills so that I don't write bad and inefficient code and proclaim 'JAVA IS SLOW' when in reality I could of done 101 things different to get outstanding performance.
Hope this helps
Re:Why use PHP? (Score:2)
You won't be getting that with Java. Not only is nothing in C, but there's so many, many layers of Java that you are working with. The plus side is that you are working with a well-abstracted framework.
Check out Webware [sf.net], which has a lot of similarities to Java Servlets, only in a nice, compact languageLike Tomcat, you're unlikely to get either of these working in shared host situations.
Re:Why use PHP? (Score:2)
Some of the reasons I like using Python for my backend apps:
myfunc = foo.bar.stuff
myfunc(1)
myfunc(2)
I'd be interested in a JSP-like front-end to Python objects as well.
Re:Why use PHP? (Score:2)
Some reasons to use PHP (Score:2, Informative)
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 [php.net] 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
Simple problem, simple solution (Score:2)
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.
Help! (Score:2)
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...
JRun is better... (Score:2, Interesting)
IMO, Simplicity isn't necessarily a bad thing...
Re:JRun is better... (Score:2)
Which version of Tomcat are you comparing JRun with?
Yes configuration of earlier versions of Tomcat is horrible, but from what others have written here, Tomcat 4 is quite a different beast.
performance (Score:1)
Apache+jserv+gnujsp: 109.50 pages/second
Resin 2.0.2 standalone: 55.87 pages/second
Tomcat 4.0 beta: 24.65 pages/second
Tomcat 3.2: 10.08 pages/second
The page I tested was the hello.jsp one that comes with gnujsp. I'm on a PIII 800 with NT 4.0 using Sun's 1.3 jdk.
I used the MS stress tester with 10 threads and 10 connections/thread. (I was lazy ran the web server and tester on the same machine.)
Apache/jserv was the only one that got no errors during the test. The rest failed a few hundred times.
I did request the page on each server to compile the jsp before running the tests.
These numbers could easily be off by 25%. What's interesting is that there's a full order of magnitude across implementations.
Re:performance (Score:2)
Enterprise Class eCommerce Applications? (Score:2)
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.
what is it that Tomcat 4.0 lets me do ... ? (Score:2)
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:
Re:what is it that Tomcat 4.0 lets me do ... ? (Score:2)
designed specifically for server applications.
That's really putting it too simply, but without getting into the details of servlet design...
Re:what is it that Tomcat 4.0 lets me do ... ? (Score:2)
And why do I need servlets? And is Java the only way to do servlets? Why not servlets in say, C or Perl or TCL or Lisp or whatever?
Re:What servlets are (Score:2)
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?
Re:What servlets are (Score:2)
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
Re:What servlets are (Score:2)
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 [slashdot.org].
Re:What servlets are (Score:2)
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.
Re:What servlets are (Score:2)
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.
Re:What servlets are (Score:2)
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.
Re:What servlets are (Score:2)
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.
Re:What servlets are (Score:2)
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.
Re:what is it that Tomcat 4.0 lets me do ... ? (Score:2)
I'd agree that fewer processes is better than more processes, given other things being equal. But is that because of performance issues? I've run benchmarks on the overhead of forking processes, and I was able to reach forking rates of over 9000 per second in Linux 2.4.7 on an 800 Mhz Pentium-III. While the overhead is non-zero, I think I'd focus on other matters where performance is an issue.
Now for Java. I like the Java language. I don't like the Java run time environment. Portability-after-compile is unimportant to me. I have not started to work with it yet, but I look forward to using gcj [gnu.org].
Separating application functionality from user interface is already a known idea, and it can be done many ways to make the components pluggable. Do people believe that Tomcat has an exclusive on this concept?
With regard to your discussion of Foo and Foo2, I don't know what you are referring to. Why can't one do this in another language other than Java? And if in Java, why is it that Tomcat is a necessary part of this?
I do worry about the apparent documentation problems. One of the things I have found that really slows down projects, whether a programming project or an administrative project, is non-existant, confusing, vague, or misleading documentation. What is it that "jetspeed" does? I'm sure it's not reading your mind and generating code ahead of your typing.
I really want to know this stuff. I want to pin down just what it is that makes all this better. And I want to isolate the different aspects of it, for example the servlets, the environment, the language, to see which of those aspects contribute what to the benefits, and to compare how those aspects can contribute by themselves. Tomcat is more than one thing, but where's the synergy? It's not obvious to me, and I hope people are not presuming it is obvious to everyone.
Re:what is it that Tomcat 4.0 lets me do ... ? (Score:2)
Java also makes it difficult to use a lot of other things, including other APIs, that exist in the host system, due to it's nature of trying to establish a standard that works across all platforms. Much of the Java API appears to be re-inventing the wheel so it has a coffee color. Now that's not a bad thing, because it does provide a uniform way for a Java program to do stuff instead of trying to access methods in other languages (which, for reasons of portability, it would surely want to deny exists).
Your statement, though, is like trying to say that the Java API is where the value is, and not the Java language. How would you feel if you were faced with another language that had an equally vast API?
Personally, I've felt that the vast Java API is overkill.
Re:what is it that Tomcat 4.0 lets me do ... ? (Score:2)
Hm ...
how do you call a perl class from a C program?
How do you call a C++ class from a perl program?
How do you call a perl class from a Java program?
How do you call a C++ class from a Java program?
A JAVA class is a JAVA class, regadless wether used in an applet on a browser or in a servlet in a web server(servlet engine) or as a bean etc.
Thats called 'code reuse'.
I know what code reuse is. Be careful, you could be coming across as talking down to people just because they don't see things the same way you do.
In general code reuse inside of the same language is more painless than code reuse across language barriers.
So?
So, use the tools in the given language. Of course Java will be a good choice because there exists the Java API. But I want to know why this means that the system should restrict one to Java exclusively, as opposed to one that allows a choice for each kind of logic element. If one page or portion of a page is more easily produced by Perl, why should this not be allowed?
Picking C++ for the moment in order to specifically avoid the OO issue, since I am addressing the issue of the usability of the API space, why is it that all this effort to produce a Java API never materialized before Java existed to produce a better API for C++? The C language has very often been said to be a poor language for many reasons, and one of them is the lack of a vast API. Well, I'll argue that the reason for that is not the language itself, but because people simply wouldn't open their editor and start building one.
I, OTOH, do that. I write a lot of code in C, and I write lots of reusable code in the form of a new API: my own library. Don't argue that it is not standard; it could be (or another API could be) if enough people had gotten involved. My point is that almost any language could have a great API if those who value the API would have come forward and actually helped build it. I'll point to the vast set of Perl modules as an example of just such an effort. People argue Perl is a great language because of all those modules. Instead I argue that Perl is a great choice despite being a lousy language, because of all those modules. Java is certainly a great language, and a great choice for what comes with it, but that the two concepts are not limited to each other.
Regarding one of your other questions/posts: no, a java application running on a webserver using CGI is not a servlet.
Someone else in another part of this subthread said it was. I was looking for confirmation or denial. I'm more ready to believe your denial. Thanks.
A servlet is a JAVA class which implements a certain interface or is derived from a base class implementing that interface.
And what if this kind of interface or base class is built in a different language system other than Java? Does that somehow negate the advantage that the interface would have in producing a servlet? In other words, I'm asking how is it that Java the language can claim to be the only way to have a servlet even if another language has implemented the same (identical, or functionally similar for example) interface?
A Servlet Engine provides runtime contexts to such a class, just like the CGI interface of Apache feeds request paramters into a CGI script a Servlet Engine descides which class to load (mapped on a URL) and instanciate and prepars the request by parsing the HTTP header and preparing parameters for the servlet.
So why is it called a servlet engine as opposed to a web service engine? Why can't these things be implemented in another language and its interfaces?
Anyway if your server is a SUN ET 10000 with >10000 served users simultaniously, JAVA is the easyer to manage technology.
And why is that so? What I want to know is if this is due to the Java language, or the Java API, or the Java Servlet Engine, or what.
One confusing term here is "simultaneously". How do we define this? Is it simultaneous when there are 9999 other request connections active while the first one is still having its content being sent to it? If that were the case, I'd focus on trying to find a way to deliver content faster so that the degree of concurrency is reduced. Is it simultaneous when there are 9999 other people in a "session" (another term to define) even though the machine may at the moment not be serving any connections at all because everyone is reading the document they have in front of them before taking the next step which would make a new request?
Why a SUN ET 10000? Sometimes I wonder if SUN made Java the way they did in order to sell larger machines. I prefer to scale up with eggs spread over more baskets instead of all my eggs in one giant basket.
Re:what is it that Tomcat 4.0 lets me do ... ? (Score:2)
So why can't I just compile my code after I write it, and run it that way? And why do I have to mix code and content? Why can't I have content (be it HTML or XML) and logic (be it in Java or C or any other language) as separate but cooperative entities, such as with tags in the content to describe to the logic where output pieces go? You're talking about some good things, but I'm still looking for why Tomcat is the only, or best, way to have this.
JSP, Servlets, PHP, Tomcat, etc explained (Score:2)
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 [apache.org] (for Java) and Smarty [freshmeat.net] (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 [apple.com]. 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
Re:JSP, Servlets, PHP, Tomcat, etc explained (Score:2)
Excellent description!
So why not have a template engine that can take a tag and find the logic element as a dynamically loaded one-function library module (avoiding a fork), or as a class file, or as a binary executeable, or as a script, or as a static sub-document? The way I'm planing my design is that each document node in a document hierarchy would specify the search starting point. The name taken from the tag is the search target. If the node is a directory, the search is for a file within that directory. If the node is a file, the search is first for a file with the node name and tag name combined, and then for the tag name alone in that directory. The search will then extend through parent directories up to the document root. And then a list of alternate directories would be searched. The search stops when the named logic element is found. This would allow some logic to have scope over the whole site or a large branch of it, while some smaller areas can have the logic substituted with a variation just for that part. For example, you can create a single logic element to output the selected ad banner HTML and put that logic element in the document root. References to it by tags in documents anywhere in the site hierarchy would then use the one at the document root. One special branch can then include a different logic element to change the ad banner logic for that branch without changing the tags the presentation designer put in to specify where the ad banner falls into the page layout. Actually the documents would be searched the same way, too.
I just don't want to force everything into a single language. I'm of the belief in using the right tool for the job, even if that means some parts of the site are done differently than other parts. I might do database logic in Java but dynamically generate graphical image files with C.
Re:what is it that Tomcat 4.0 lets me do ... ? (Score:2)
You're thinking of templating engines, and there are many around. Probably more by co-incidence than anything else, the ones I've come across have all been written in Java, and co-operate nicely with Servlets (this is where Tomcat fits in).
But the concept of a "template engine" as you understand it, doesn't specifically require Java, and could be done in say C? So Tomcat is a "template engine"? And the templates are in XML?
Have a look around at Velocity, Webmacro, FreeMarker or Tea (see my earlier post above, or Google for them), and have fun!
I'm sure I can find them. But conceptually, what are they? Are they template engines? Servlet processors (if there is such a term)? Ya know, a "concepts document" (that specifically does not depend on the reader already understanding the abstract concepts it's expected to explain) would go a long way to clarify things here for me. A "concepts document" is, unfortunately, a very rare thing in most things.
Re:what is it that Tomcat 4.0 lets me do ... ? (Score:2)
A good introduction to the concepts behind template engines can be found at Servlets.com [servlets.com], along with its followup article [servlets.com].
I'd like to take a look at these documents. Unfortunately the site has been down since yesterday. Do you know when it might be back or where a mirror would be?
Re:what is it that Tomcat 4.0 lets me do ... ? (Score:2)
That's a fairly standard model. That's not specific to Java, J2EE, or Tomcat. What you do get is that in some environments, the 2nd and 3rd are not separated (or maybe not very well). PHP comes to mind.
I built this [linuxhomepage.com] site with PHP in one day and it was my first PHP project. The backend (1st in your list) was written in C and a shell script and not built on a usual SQL DB engine. It just consists of a cron triggered script that fetches backend data with lynx and reformats it with a different C program customized for each site (some in text format and some in RDF which was added later). The PHP code can be seen here [linuxhomepage.com].
But I have concluded that fully integrated logic and presentation is not a good thing. And I've also concluded that more than one class of logic can and should exist in a single presentation. The logic to select the banner ad should be separate from the logic to summarize some news on the side rail, while yet different logic selects the main forum body (in an example forum site). I feel all those elements should be discrete reusable elements of logic. The ad banner selector could be used on other pages, for example. The page would then be built for layout and style much as a regular static web page would be, with tag elements to notate where other "sub-presentations" go. Those can then be other static elements, or logic (dynamic) elements.
I have thought this was what JSP was supposed to be about, and the logic elements would be servlets. But I don't see where it has to be done in Java. Now that doesn't mean I hate Java. I admit I dis-like C++, but not Java. I do OO design and code it in C, but I haven't found any real advantage to doing it in C++. But I've done some programming in Pike, which I believe is better OO than C++ (but also has some limitations). Java looks to be the current state of the art in reasonably clean OOL.
The trouble I have with Java is the JVM. I don't feel the whole portable environment thing is necessary for statically maintained applications. What I mean by that is something that stays where it is sufficiently long term to make a compilation worth while (a day). To make downloadable applications to run in a web browser, portability is now more needed since a site needs to be able to deliver something on demand that works on many different platforms. But for this I don't feel that a compiled to byte code environment is the right way to go. If Java had been compiled down to a stack engine environment somewhat like Forth, or maybe just use Forth, then I would have agreed with it.
Basically, my goal for the server side is to have an environment that allows working with elements in the binary format of the host machine compiled from C or Java (for my choices) or any other language (compiled to binary like C++, precompiled like Perl, or interpreted at run time like Bash) that can run on the host, and integrate those as logic elements in a template based server engine. I see Java as a good choice in the system, but I also believe it should be that, a choice.
I'm currently designing a new server which will eliminate the forking in certain cases. Assuming you don't have a switch-userid problem (which would require some kind of forking somewhere) the way it would work is that a piece of logic would be coded in C and compiled not into an executeable but into a simple module file with a .so extension.
The template processor would parse for tags (and I have planned a parsing cache for static templates)
in the template, and for those it finds, it would "call" the appropriate element for that tag.
That could be another template (recursion loop detection engaged) or some logic.
If the logic is the .so file, then it would be loaded as a dynamic library right then and called directly in the same process.
If the logic is an executeable file (or a module owned by a different user in a switch-userid situation),
then it would be run in a forked process.
The point of the design is that all the elements can be made from any kind of executeable element the host OS can handle.
And that would include Java, either as a binary compiled module (if I can figure out how to do that),
a binary compiled executeable, or as a class file run by the appropriate byte code engine.
Re:what is it that Tomcat 4.0 lets me do ... ? (Score:2)
Take the Java language out of the picture for a moment. Plug some other object oriented language in. If history had resulted in a different language than Java, but all the web application framework and tools had been developed, would we have all the benefits we have today?
Obviously you think I have some kind of attitude because you expressed that. But I think you have simply mis-interpreted what I did ask, and still am asking. I'm not saying Java and all that comes with it is bad. I'm trying to isolate what benefits come from the various pieces, and what benefits come from the synergy, and what synergy is dependent on the various pieces. All of the literature I have read about Java as a web development environment simply doesn't address that. It probably doesn't because the people promoting Java either think it is utterly clear to everyone (it is a common human trait for people to think that what is obvious to them is obvious to everyone, even though it is not generally true), or else they think that understanding this about it is just unimportant (i.e. that everyone should take it on faith that all this is good because they say so).
Of course an application scaled up to the level which does require a hundred developers has very different needs than one that can be done by one or two people. I want to hear someone say just what they think the whole Java based web development system is good for ... where is the threshold? Not all applications are enterprise scale, yet many Java promoters are coming across as saying that it is best for everything, and when they also say "enterprise class" it sounds like they think everything fits that description.
And yes, I have seen, and participated in development of one part of, a application of this scale. There were over 250 developers involved (most of whom I never met or even communicated with ... that was the job of the project managers). BTW, it was all done in C at the time, and when I left that company, they were starting to work on a transition to C++. I can believe they have switched (or are in the process of doing so) to Java by now. Their particular application requires continuous development because it involves a continuously changing business process.
Re:what is it that Tomcat 4.0 lets me do ... ? (Score:2)
I think there is an assumption that any web development that is not based on Java and its web development environment is instead based on mod_perl, mod_php, or CGI. To the extent that may be true it is due to what has been developed, as opposed to what could be developed. I believe that the framework could be done in most languages. Somewhere along the way, that didn't happen until Java came around. But why? Is it because those who would think of it were not inspired to do so until they saw Java? And if that is the case, what is it about Java that inspired them? Obviously it is not OO concepts alone because C++ would have inspired them if it were. Is it because Java is a clean OO language? Why not Smalltalk? Is it because all this was really promoted and pushed by SUN? I tend to think this is the answer. That does not mean that it is bad, but it does tell me that the scale of acceptance is not telling of the capabilities. I want to see the capabilities stand on their own. It's like why people choose to buy some widget. The salesman tries to tell me that I should choose to buy the widget because a million other people have. What I want to know is why those million other people did, and of those who did make a wise decision to do so (if any) what knowledge and information did they use to make that decision that this salesman is not willing to tell me in favor of claiming the million buyers.
I don't want to choose Java or Tomcat because everyone does. I want to choose it because there's something good about it, and I want to especially know if that can't exist in something else (even if it doesn't, yet). And this is required before learning it. Of course I could simply presume it must be good, spend the time to learn it, then determine if it really is or not. But by then, I've spent more time learning, less time developing, and looking at a full plate of projects I know have to decide whether to go ahead and use something new I've learned which is most certainly better than what I had before, even though it might not be as good as what could be (if framework developers had been inspired earlier). Then I'd end up being "one of those who use it" and counted among the millions, even if I might have not made the choice if I had know what I needed to know to make a wise choice (for my needs). I worry that the popularity is not 100% from people who found out what it really does for them and then decided.
I do agree that CGI (it's an interface, not really a protocol) is bad. It's a useful hack for small things and I've used it a lot. I've used it enough to know I want something better. And I am working on the design of something better. It is a template engine based on modules. It can be done object oriented, but it doesn't have to be. It can use strictly modules, or it can do other things, even shell scripts (if you want to, but then it starts to look like CGI again ... but at least the choice exists).
I'm also designing it for a smaller scale than "enterprise class" applications.
In that sense it would not be competing with Tomcat or J2EE or JSP or whatever.
Development on the scale of one person-day projects could use this over CGI.
People point to Java for "enterprise class" purposes.
But I don't know that what is good for that scale is necessarily good, in whole,
on the smaller scale.
But if there are parts that are good, they should be used.
Now the question is, can they be used on their own.
To the extent my project will use those parts, we will see.
Re:what is it that Tomcat 4.0 lets me do ... ? (Score:2)
Those concepts are good ones, even on a smaller scale. But they are not exclusive to Java. Despite the fact that I believe Java is a good language (and perhaps the one I have been holding out for instead of going with C++), I want to know exactly what concepts can't work with any other language, and what concepts can. I believe they all can work with other languages, and that the issue really comes down to developers using what exists today that best solves their problems. My interest in development personally is not so much developing an application, but developing frameworks within which applications can be done. And I'm more interested in the smaller scale (which is apparently not where Java and/or what comes with it today) shines best (confirmed by so many references to enterprise class applications being far too difficult in anything else).
Re:Tomcat lacks documents? (Score:2, Informative)
Re:It's no use if you want to use it on your web s (Score:2, Informative)
Jon
sigh (Score:2, Insightful)
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
very nature of dynamic scripting languages? (Score:2)
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 [sourceforge.net] 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 [slashdot.org].