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)
Maybe they can finally get code red to work in this version.
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! :)
I'm color-blind, and this scheme still hurts.
I think my retinas are bleeding now.
NOBODY expects the Spanish Inquisition!
--
This sig intentionally left blank
I'm only using version 1.3.18 right now, so this will be quite a huge upgrade for me! Quite cool, I'll be downloading and compiling the new version tonight!
I hope the communicuty relizes what a big deal this is for linux, and will promote it accordinly. Lots of people are looking for ASP, Cold fusion, and Perl alternatives as their applications scale beyond what scripting languages are capable of. Once a project reaches a certain level the very nature of dynamic scripting languages becomes a burden. Anyways the real point is that this will finally make companies realize that they can run their very important intranet/database applications using linux and without wasting lots of money on stupid middleware.
Anyone know a good place to start learning about Java Servlets and, in particular, how to implement such programs with Tomcat? The last time I tried, it was a major hassle to get even the sample applets running, and I would like a fresh start.
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
The project is called Jakarta, not Jakarata:
Read more at The Apache Group's Jakarata site.
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'm just waiting for Jon Katz's next ill-considered, ignorant and naive political rant! I just can't get enough of his stupidity. Maybe he can spin it off into his own idiotic website.
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...
This tutorial is really good and very easy to
follow, even though - or maybe because - they
plug blazix on windoze as the demo engine.
Which works remarkably well, I must admit.
The tutorial is generic, so you won't pick
up anything specific to Tomcat, but last time
I looked getting Tomcat to say 'Hi mom' was
simple enough.
Also, unrelated, their www.ejbtut.com is
doing a fine job getting mortals started with
J2EE EJB.
the ajp12 and ajp13 protocol are those used btwn the Apache Web Server frontal and the multiple Apache Tomcat instances ....
I just did a very informal test of a few implementations:
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.
Big lips => good seal
The Java and J2EE give you an environment
.net it will
guaranteed to be free of the Evil Empire(tm).
And it just makes plain sense, archtecturally
speaking.
If you want it as open source, there's still some
work left to do, but at least it's possible.
The Apache project is doing an excellent job,
and Tomcat is living proof that Sun is willing
to cooperate with the OS community (although
they could open up their reference implementation
some more).
But make no mistake, if M$ can gain any
significant market share with
leverage it's OS dominance to make it dominant.
Pretty much everything is at stake:
Linux+Apache+JBoss+Postgres != Windoze+IIS+.net+SQL Server
For a completely Free solution, check out http://sources.redhat.com/rhug.
Create native shared libraries for xalan, xerces, tomcat, which native shared library servlet support. Requires the very latest gcj and runtime from the GCC development sources.
Just "configure; make; install; tomcat"
The Turbind development kit on the same site
has a working sample app.
All of the Jakarta developers work for Sun.
The Subject line says it all, Tomcat needs good documents. The current FAQ is just not a good way for new users, who don't even know what they should be asking. And please don't assume the user know much about JSP and Servlet during installation. Many, like myself, just want to install it so we can start learning JSP! The latest version of web.xml and server.xml now contain more verbose comments on various settings, which is a big improvement on the old ones.
The Apache document is a good example of how it is done. It contains details on every single configuration options and plus entire chapter on common tasks (eg DSO, Virtual Host). The Apache default conf file is probably the best commented of its type out there, sometime you don't even need to refer anything else to fully configure your installation!
Note that this is NOT an attack on Tomcat as an application, once it is installed by someone who know what they are doing, it runs great. It is just that the initial step is very difficult for many people. Hopefully now that 4.0 is out, the developers can spend more time on documentations.
Codeala - Just another mindless drone
For all you OSS kids out there who are beaming at everything the Apache group puts out like it's gold dust, maybe it's time to look a little bit further afield if you actually care about performance, robustness, scalability, and general developer friendliness.
I can't speak for any of the rest of the Apache group, since I have no experience with that side. However, I can safely say that the Java Apache group on the whole puts out some truly awful things, that only make it because of the clout and rep that the 'Apache' name brings.
Tomcat is supposed to be a reference impl of the spec as put forth by the servlet expert group. In reality, the tomcat people are on that expert group, and do their utmost to spread a broken spec because 'we implemented it that way'. The spec has a number of very annoying failings (with regards to filters and request dispatchers, as well as context issues) that only made it in because the tomcat folk thought it's too hard to implement these properly. It's ludicrous that the spec suffers, because of incompetent vendors who have too much clout.
The only java project at Apache that works and works well is ant, the rest of the useful ones are those that moved under that umbrella and grew outside of Apache (log4j, oro). ECS is a horrific idea, Slide doesn't work in any useful manner, Velocity is a ripoff of webmacro/freemarker), etc etc.
It's a tight knit group of part time developers, with fairly fragile egos (obviously, this is a general perception, not 100% accurate!), who often get hugely defensive about their impls.
At the end of the day, what matters to the end (business) user is how well the product performs, how well it scales, and other such measures. I can guarantee that tomcat is bottom of the list in any benchmark you care to run against any modern servlet engine. Yet, it's hailed as a success story. Open your eyes!
if you want a real servlet engine, go with Orion or resin (or even jetty).
I just installed the 4.0 dist and when i hit http://localhost:8080, I see the following:
Tomcat
Version 3.2.3
Along with that, all the online docs are broken. Does anyone else see this?
yeah I've used both resin and tomcat and found resin easier to configure and use
kudos to the jakarta team!
from download to install and http access (on solaris 8/sparc) in 5 minutes!
servlet filters will be very useful (been using a similar feature with atg dynamo for a while now). in fact, tomcat has a number of very useful features that are normally found in the pay-per-use java servers. when the new apache module (to tie the ws in with the js) is done, this will be a kick-butt combination!
anyone not already in the java server game should give this new beast a try. the sample application (structure and ant build config file) makes getting started snap!
don't forget to d/l CVS to keep your projects straight!
Mind the gap...
Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software complete and unmodified for the sole purpose of designing, developing and testing your Java applets and applications intended to run on the Java platform ("Programs").
Anyone know of a JVM that I can use for a production server?
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
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
2.3 still isn't final :-)
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
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.
The Apache group releases yet another world class product...
i'm glad to see that the Jakarta Project's latest release of Tomcat comes with more documentation and administrative tools than the earlier 3.x releases. Not that those were hard to install and configure, but when you're trying to get Management to let you use a product, it helps to have more warm fuzzy ways of doing things, than the old "well i can edit that config file and we'll be ready to go"
of course there are still some documentation pieces lacking, (like whats the WARP protocol?!?) but overall it seems a really good, well rounded release of the Tomcat product.
of course, i still havent found how i integrate tomcat into an existing web server other than Apache...
Uh, that's just the SDK.
You want the JRE (Java Runtime Environment) for the purpose of deployment.
Probably the only application server you can have up and running in 2 minutes. Plus since its all python based, you can get tracebacks and debug the thing live. Lots of cool new method-specific caching features all built in. DAs for lots of different DBs, transactions etc. Solid community, BBSs, CMS, image galleries etc. Check it out! Ya might like it.
Interactive Visual Medical Dictionary
And why do I need servlets?
You don't need them per say. But a lot server-side applications are written as servlets.
And is Java the only way to do servlets?
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.
Why not servlets in say, C or Perl or TCL or Lisp or whatever?
You can write server-side applications in any of these languages, they're just not called servlets.
- Scott
Scott Stevenson
Tree House Ideas
The JRE has the same clause in its license, i.e., it is for development & testing only!
Finally this version seems to add some kind of Unicode support for HTTP requests. Lack of this before has been very strange, cause i18n has always been built in Java.
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
Having once been dragged screaming from my cozy, fast and functional PHP nest and been forced into whipping some (very highly paid) Java programmers' woeful attempt at a web-based GUI that used Apache/Tomcat/Linux into some sort of shape, I can attest to the following facts:
Admittedly the project I was strong-armed into was particularly ill-suited to JSPs, and I had no experience with Java, but it wasn't Java I had a problem with. I'm a web-app designer and I can do that largely irrespective of the language used.
It's just that the idea of (in a software product) bumping the user's hardware requirements up by about 50%, and the application's total size up by about 100% just to use JSPs for the configuration interface really blew my mind.
Please help stamp out this fucking stupid technology so noone else has to go through the sort of pain I did. (All for nothing as it turned out. 2 days after I'd finished rewriting the Java gurus' HTML code - a 3 month job since they were still writing more shit code as I was fixing what they'd already done - they whole project was canned and all staff layed off.)
I decided to re-write the interface in PHP as personal exercise to fill in some of my now plentiful spare time. It took me one week, worked perfectly, and was considerably faster.
You know they call 'em fingers but I've never seen 'em fing. Oh, there they go.
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
I've been trying to check out some of Apache's advanced offerings, but I can't get much beyond Jakarta. Specifically, I've wanted to check out Cocoon and Jetspeed.. to check out the free portal offerings before trying out my employer's offering, IBM Enterprise Information Portal.
./setup.ksh (IBM loves Korn Shell :) then the free offering will definitely fall way short.
Jarkarta is easy to get running. I can get the sample servlets running in just a few minutes. Yet I've had the summer off, and have never gotten Cocoon to run once. The closest I've gotten was the famed "Internal Execution Error: servlet not initialized". I can tell you its extremely frustrating to think you have *finally* found the configuration error only to see the same result for a couple of months.
Perhaps my problems stem from not having any Java experience to build from, so I'm not even sure how things like CLASSPATH work. Sometimes I've seen CLASSPATH include a directory like a normal PATH declaration, but then I've also seen CLASSPATH declarations include specific jar files. I've been able to get IBM's Xeena and the Alice chatbot to run under Java, but forget about these complex setups.
I'm also never sure if the jar files from the twenty supporting packages you have to download and install before Cocoon or Jetspeed need to be copied to $JAVA_HOME/jre/lib/ext or just have variables like $ANT_HOME defined. Its a real daunting task for a true Java newbie. There doesn't seem to be a definitive word across the documentation on how these things should all be installed. In particular, there are some jar files that are either multiply downloaded (xerces and xalan come to mind) or don't exist anymore. Would someone at the project actually listen if I submit corrections to their documentation?
I finally said "f-it for now" and I've moved on to PHP-Nuke. If its that hard to get started, I don't even want to know what it'll take to maintain or upgrade it. Plus I can run PHP-Nuke on Sourceforge. I didn't want to move on to IBM's Enterprise Information Portal until I had a free offering to compare it to, but if it's a matter of rpm -ivh or
Intelligent Life on Earth
D/L Sun's Server Hotspot engine!
It's characteristics make it slower on startup (wouldn't want those Windows users to have to wait for their Java gamelets to load now, would we?) But once it's running, you will see a significantly different performance heuristic.
http://java.sun.com/products/hotspot/
1. Create WAR file
2. cp WAR file to $TOMCAT_HOME/webapps
done. You guys are having problems with this? Installing jserv was much harder -- you had to compile it, and then change the httpd.conf to work with it, and set up tomcat to listen to the right directories.
Working with Tomcat 3.x is one of the most painless experiences I have ever had.... Except for when a JSP doesn't compile, it doesn't give you a very good message.
-Mike
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
As to the ~username/file.jsp problem, I recall that you can map extensions (i.e. *.jsp) to tomcat. There was a tricky part if your jsps were in a different directory than your html files: you'd need to stick an empty file of the same name in the html directory, to let Apache know that it should try to return something. Someone out there has a better solution using mod_rewrite, but the empty
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.
I sincerely hope that it's better than Tomcat 3.x. We have worked with all versions between 3.2 and 3.2.3, and it's gotten better - but not great.
There are still some concurrency issues under heavy load that makes it go belly up.
Besides it's not excactly lightning fast. We've seen factors of 10-20 times the performance on other Servlet containers.
Well, I guess that's what we've got innovation for!
-dennis
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.
In this vein, see an introductory article ("Server-side Java with Jakarta Tomcat") in Linux Journal (April, 2001) in the regular column, At the Forge.
A lawyer & digital forensics examiner. Also an expert on open source software (OSS).
Hello Curly,
It sounds like you're awefully angry and I'm sure there are people who will agree with you, but I'm not one of them. You say:
o "Anything you can do in JSP you can do in ASP and..."
I simply don't agree. The JSP/Servlet layer enables you to build systems using both extensible MVC framework and patterns plus use and XML. ASP doesn't. No such software design has been provided in ASP. Now ASP will be supported by OO languages and Microsoft has the opportunity to use and incorporate patterns. However the people responsible for ASP have spent the past five years ignoring the only OO languages Microsoft had: Visual Foxpro and J++. So its anyones guess as to whether ideas like MVC, cohesion, and decoupling are on their agenda yet.
o They are "insanely difficult to debug"
Have you considered that you're possibly making erroneous assumptions about what JSPs are or how they work? This is easy to do. Many people think JSPs are just kind of some sugar coated HTML. In fact, the lack of coherence in language design of such scripting facilities kept me away from them for a long time.
Also, I would think that your not being familiar with Java could make you seriously frustrated with JSP.
One of my early takes on JSP was that it was a way to avoid writing Java. When you instead look at JSP as a time-saving facade for programmers who actually *do* know Java, it takes on a completely different meaning.
o The hammer vs. nail thing and the "management loves it" thing.
Been there done that. These are "everyone here's against what I want and they just don't understand" positions. The hammer/nail thing applies to any new solution - there are going to be people who advocate using the same solution for everything, large or small - because that's what they know about. And "Management" is a word used by people who unfortunately have bad managers. (See bad-managers.com "True stories of disasterous projects and cowboy managers").
Both Hammer/nail and "management loves it" has be said about mainframes, about Microsoft and about Visual Basic.
Most recently, I've even seen it about C++. And before that C. And both attitudes helped kill the companies that held them.
Originally, although I was coming from a somewhat different place from you, I felt the same way about JSP - that it was designed to be "like" Microsoft's ASP and that was not the right approach. But now I think JSP has proved its worth. There are people who have been successful with JSP, have put a lot of time into it, and have benefited from it.
I'm glad you are successful with PHP. But there also going to be many who will resent you for calling JSP a "f_____ stupid technology." I don't think it's worth swearing at or asking others to "stamp it out" for you.
In fact, although I'm definitely not the worlds number one JSP advocate, I even resent your swearing and hostility at JSP and at Tomcat, since the fact that you put this in the Tomcat thread, and at all the people who have worked hard to make Tomcat work.
So, if it was your intention suck someone in with your negativity and make them upset just because you're upset at people you had to work with - then congratulations. You've succeeded.
My only advise is, express your feelings to them. Or let it go. Or both. There are too many good things to do and not enough time to do them to be stay hostile at a whole technology.
I'm sorry that it didn't work for you, and I do know the feeling.
Regards and best wishes,
Rich Katz
I don't see why you say the OSS community has some "mistrust of Java and Sun and anything related to them." This description seems both dismissive, and inflamatory. It depends on a somewhat exclusionary view of OSS - a view that I would categorize as "misguided" to say the least.
I'm not saying you should or should not use PHP or advocate using PHP, but I think your statement about OSS could be a lot kinder.
Tomcat itself is open source!
Or do you not include Apache in your "open source definition?" And many products based on Tomcat are open source!
Or don't they count because they aren't written in PHP? You've apparently dug some mental Grand Canyon between non-Java open source and Java-based open source so that one can be called OSS while and the other is called "mistrusted?"
Regards,
Rich Katz
"Binary and source distributions of the mod_webapp connector will be posted on Wednesday, September 19, 2001"... Hm, well... Now it is already September 21, 2001... I would like to see tomcat-4.0 in action together with apache!
Howdy, Rich.
/. readers are people who are, or who soon will be, making those decisions.
I guess I was (in the job I was refering to) more frustrated than angry - I'm a pretty chilled-out soul all things considered.
You raise some excellent points, and ones that I cannot disagree with. My problem is with the buzzword-laden promotion of this technology as the "one solution fits all" solution, which is an avenue that I'm sure you'd agree is a rocky garden path down which to lead any project (to mix a few metaphors just for the hell of it).Admittedly in the light of day my post was somewhat rabid, but if it helps stop one more company wasting ridiculous amounts of money and time, and indirectly screwing up an entire project's future (and let me a that this point say that this is *not* some Mom and Pop outfit we're talking about here) through sheer ignorance and force of advertising (of Java, by Sun), then I'll sleep easy despite my 0: flamebait rating for it.
I am by no means denigrating Java. Yes it was a pain to learn (from a self-taught programmer's perspective who's given 2 weeks to learn the language and de-fuck-up the Javaissimo's shite HTML generating code), yes it was unsuited to the project, but ultimately the decision was made by the gulliable management (ok, no, I can't spell gulliable).
Furthermore, we ended up using a hugely complex XML-based configuration interface which (*after* hiring the 2 Java gurus) it was decided would be needed to configure this fairly ordinary system.
It was a chicken and egg situation. Once the Java guys were hired for the GUI, everything had to be centered around Java's requirements and abilities.
In a parallel universe the GUI could have had it's back-end written in bash shell script and been just as compatible, functional, and probably faster. And written, leveraging the combined *nix experience of the devel team, in a week or two.
Considering Java's requirements were approximately twice what our core application's were, this was distressing to anyone involved that had a sense of design or any pride in the quality of the product they were producing.
It needs to be understood what Java is and isn't good for. That seems to me to be the key to making good technology decisions, and
Anyway, I've enjoyed both the +1 posts on this, and it has been a heads-up, but I'll stick to my original pricipals of KISS, and say that unless one actually *needs* to leverage some specific Java capability, it's overhead outweighs it's benefits for web apps.
Cheers, folks.
You know they call 'em fingers but I've never seen 'em fing. Oh, there they go.