Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Apache Software

Apache Tomcat 4.0 Final Released 288

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

Apache Tomcat 4.0 Final Released More

Apache Tomcat 4.0 Final Released

Comments Filter:

  • Tomcat looks good (Score:5, Informative)

    by claes ( 25551 ) on Tuesday September 18, 2001 @05:30PM (#2317447)
    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.

    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 .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!

    With a strong XML foundation in place, Java's future is looking really good.
    • Java has become a competitor to .NET? .NET is not even reality yet.
      Java has strong infrastructural strengths already (and have had so since day 1).

      OTOH, once .NET gets going we'll have the best of breed virus platform
      that supports any MS programming language (and more!) of your choice :)

      • OTOH, once .NET gets going we'll have the best of breed virus platform that supports any MS programming language (and more!) of your choice :)

        Yes, but will .NET be able to get Evolution on my RedHat 6.2 PC to run Outlook viruses properly? That is, immediately and with little to no intervention on my part?
      • No doubt. In order to be the ultimate platform of corporate choice, .N3T will guarantee backwards compatibility with all Outlook, Windows, DOS and CP/M viruses.

        "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.

  • very cool (Score:5, Informative)

    by Dalroth ( 85450 ) on Tuesday September 18, 2001 @05:33PM (#2317467) Homepage Journal
    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! :)
    • The configuration files for Tomcat 3.x look like they were designed by a monkey on crack (or a Sendmail developer)

      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.
  • 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!
    • You're thinking Apache HTTPd --- this is Apache Tomcat, a Java Servlet container and JSP engine. Get with the program! ;)

      Still, please try it out. Tomcat rocks! Many thanks to Craig, Remy, and the other developers who made Catalina a reality.

      Mike
  • 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.
    • Try the O'Reilly books on JSP and Java servlets (I much prefer servlets to JSP, but that is just my preference).

      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.

    • Where better to start than Sun's own tutorial [sun.com]?

  • WOW - 6 hours (Score:2, Informative)

    by icoloma ( 322750 )
    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! :)
    • Yeah, Tomcat guys were saying on the mailing list that they would call the last beta a "beta" until Sun puts a seal on the spec because they were ready much earlier (pending any changes in the spec that is). So basically as soon as they found out about the spec approval they just branched the code and made the build. It's all in their mailing list.

  • And that also means... (Score:2, Informative)

    by vanza ( 125693 )
    That the 2.3 Servlet specification and 1.2 JSP Specification have been released [jcp.org] as final.

  • Hehe (Score:3, Insightful)

    by JediTrainer ( 314273 ) on Tuesday September 18, 2001 @05:49PM (#2317563)
    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!

    • Re:Hehe (Score:3, Informative)

      by Dg93 ( 10261 )
      The 3.x and 4.x trees are completely different codebases... My understanding is that the 3.x tree will continue to get a certain amount of maintenance and development while the 4.x tree gets shaken out.

      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)

        by JediTrainer ( 314273 )
        The 3.x and 4.x trees are completely different codebases... My understanding is that the 3.x tree will continue to get a certain amount of maintenance
        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)

    by (H)elix1 ( 231155 ) <slashdot.helix@nOSPaM.gmail.com> on Tuesday September 18, 2001 @05:58PM (#2317600) Homepage Journal
    Download the file - lets say on a Win2K they have locked down at work. No admin rights? no problem... (Win2K assumptions here, though most OS's work about the same)

    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!

    • most OS's work about the same
      ...
      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 :)
      • Don't know about your configuration, but mine has no problem with it. (Reminds me at some Opera Beta Version)

        Just "cd c:\\jakarta", but about that startup.bat, how am I supposed to run that thing :) ?

    • Re:Very Mini howto... (Score:3, Informative)

      by hansk ( 107187 )

      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.

      • I'm running without a CATALINA_HOME, and it spins up fine - jsp, servlets, and JavaBeans... The howto was just to get folks up and running with a stand alone version, without the clutter of extra stuff.

        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...
  • I haven't looked at it yet but my first question is:

    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)

    by Teancom ( 13486 ) <david&gnuconsulting,com> on Tuesday September 18, 2001 @06:02PM (#2317623) Homepage
    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.

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

    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 hear you loud and clear. But if you think you've seen the worst in terms of installation woes you should check out IBM Websphere. Oh, man two months since 4.0 shipped and I still haven't got it all running. What a f***ing nightmare!
    • Thats OK, I fought with tomcat in Debian unstable, it installed but wouldn't do it's magic with servlets and jsp like it was supposed to. I finally gave up and grabbed the tomcat 4 beta binary from Apache's site and everything worked properly. I might have another go round once this makes it into sid.

      Maybe you could write a script that did the configs for you?

    • I don't know what happened between Apache JServe [apache.org] (Servlets 2.0 and JSP 1.0 via things like
      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)

    by coyote-san ( 38515 ) on Tuesday September 18, 2001 @06:02PM (#2317626)
    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.)
    • From what I've read on the Tomcat-user list, Tomcat does not do EJB and JBoss is the usual recommendation.

      LEXX
    • Use debian unstable, which I've been using at work and at home with hardly any problems. It's really not unstable at all. With that, the release cycle is every six hours or so :)
      • I usually update when they go into a release freeze, but 'unstable' really is too unstable for me to use. I've been burned in the past, and my spare systems (P-166) are too limited to do some of the necessary work.

        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.

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

  • Tomcat As the Anti.NET? (Score:4, Interesting)

    by Lethyos ( 408045 ) on Tuesday September 18, 2001 @06:11PM (#2317666) Journal
    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.

    Tomcat has tremendous potential to deliver robust, complete apps in the same way .NET wants to. And, it's not restricted to Windows.

    Is my thinking correct in that we can level this software against Microsoft's upcoming ventures? Can we make a .NET killer out of this, or am I thinking about driving a screw with a hammer?

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

  • slightly offtopic, other jakarta stuff (Score:3, Informative)

    by frknfrk ( 127417 ) on Tuesday September 18, 2001 @06:14PM (#2317682) Homepage
    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 [apache.org].

  • J-Run (Score:2)

    by ajs ( 35943 )
    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!
    • Well, Tomcat is a web server (jsp and servlets) and J-Run is an application server (EJB). No- they are not competitors.

      Does that answer your question?
    • It depends on which version of JRun you are talking about.

      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)

      by jefflinwood ( 20955 )
      Yes, they're competitors in a way.

      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)

        by Tsujigiri ( 77400 )
        And if you do need EJB support, give JBoss [jboss.org] a look. It's open source and intergrates well with Tomcat to provide the EJB side of things.

  • Why use PHP? (Score:2, Interesting)

    by heretic ( 5829 )
    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.
    • Well, we use JSPs because everything else we do is 100% java so it makes sense for us. Having said that though my personal and very subjective experience is that PHP pages are quite a bit faster than those generated by JSPs. Obviously it's nearly impossible to benchmark those things byut from experience I'd say that it's easier to create fast pages in PHP whereas with servlet/JSPs it's easier to create robust pages. Not very scientific I know, but here's my $0.02 on the subject.
    • why PHP is so popular when JSP provides a much more robust solution

      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.
    • Hope that's a typo and you're not really getting JSPs and JavaScript confused - they are two very different technologies with very different uses.

      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:2, Informative)

      by jefflinwood ( 20955 )
      One big reason PHP is popular is that servlet/JSP web hosting is expensive compared to PHP for small sites that use shared web servers. If anyone knows of any cheap (less than $15/mo) places that let you run your own servlets against a database, let me know.

      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:5, Informative)

      by crisco ( 4669 ) on Tuesday September 18, 2001 @07:09PM (#2317911) Homepage
      • Because Java / JSP is just getting to the point of ease of use that PHP was a couple of years ago? In terms of strength as a language and a platform, JSP and Servlets have PHP beat. But the entry level is much higher, think of the arcane xml files to get your programs working in the directories you want. With PHP you just drop things in and they work, often easier than CGI. Consider how many people start, diving in and messing with code. Now imagine you wanna do that with a servlet? Not that it is difficult, it is just a little harder than with PHP.
      • Because PHP / MySQL are standard at many cheap webhosts and with many Linux distros? And jsp / servlets aren't.
      • The OSS community's mistrust of Java and Sun and anything related to them.
      • Momentum and established codebase. Need a shopping cart, weblog, photogallery, or bulletin board? Head over to freshmeat and take your pick of PHP and Perl solutions. Want it in Java? Hmm, slim pickings...

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

        • Oh no, I absolutely agree, PHP would probably be a nightmare in those 'enterprise' situations. And that is an absolutely great point, right tool, right job.

          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.

          • regarding your 'shopping cart': you should probably move from MySQL to Postgres. Yes, yes, I've heard all the carping from MySQLers proclaiming that you don't need transactions in most cases, but when your bits start representing dollars, you should consider that one of the 'important' cases.

            Better speed, too.

    • Personally,

      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 ;-). I have found that in pure database management java can be much easier if you use the right tools. I personally am VERY effective using JBuilder in Linux to build JavaBeans and then dive into VI w/the webdesigners on implimenting them with JSP. I know that there are various other template systems out there, but we are very comfortable with the quarks of JSP and once you spend the time getting used to the ERROR messages of JSP, it's hard to let go. (Maybe like learning REGEX syntax of perl?:)

      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 .. it will REALLY let us choose the best tool for the job, and communicate openly with other 'best of breed/for job' tools.

      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. ;-) But understanding your OWN limitations and abilities as a programmer is JUST as important as picking the right language, some people are just not ready for some languages. Some people don't have the patience to finish the job correctly with a System level language, as some do.

      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

      • One other point, I have never gotten myself into a performance hole with PHP, Java I have.
        I have a feeling this has to do with levels of abstraction and layers of code. PHP, with a rather weak object system and a tendency to use so many global variables, tends not to encourage many levels of abstraction. You write in terms of the primitives of the language -- of which there are a lot. That's fast, you're running lots of stuff that's implemented in C.

        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.

        I personally am still waiting for a viable alternative to Zope as Python is my language of choice
        Check out Webware [sf.net], which has a lot of similarities to Java Servlets, only in a nice, compact language :) I've never programmed Java Servlets, but the Hello World examples I've seen look absolutely painful. Anyway, I like Webware a lot. A slightly more recent arrival with a less Java feel is Skunkweb [sf.net]. I haven't used it, but the developers seem like competent and friendly people.

        Like Tomcat, you're unlikely to get either of these working in shared host situations.

        • Some of the reasons I like using Python for my backend apps:

          • Objects can be copied to local names to avoid dereferencing the same object over and over again:
            myfunc = foo.bar.stuff
            myfunc(1)
            myfunc(2)
          • Adding new C-compiled functions to the system libraries is quite easy and allows you to implement speed-concious code as tightly as possible.
          • Objects are easily serialised with Pickle and can be stored in a database field to be retrieved later, with all their state stored properly.
          • It has a good concept of scope and allows for nested functions.
          • It allows me to use casting on variables, like C, and check variable types, to avoid common programming errors.

          I'd be interested in a JSP-like front-end to Python objects as well.

    • 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 [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
    • Most web publishing problems are not terribly complex. Creating a solution in a simple language that provides good database connectivity makes a better fit than an overly complex solution.

      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.

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

  • JRun is better... (Score:2, Interesting)

    by hendridm ( 302246 )
    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...

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

  • 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.
  • Tomcat and Jakarta are wonderful, however does anyone know of any enterprise class open source applications or application servers that provide functionality out of the box for things like billing, subscriptions, content management, CRM, product pricing, cross selling, settlements, personalization, call center support, etc.? I'm not talking about simple storefront type stuff that mom & pop companies use, but robust applications that support complex product pricing and bundling? Or an application that provides robust CRM? I'm thinking open source versions of products like Blue Martini, Broadvision, Siebel, Portal, etc.


    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.

  • 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:

    • Apache with mod_perl or mod_php
    • Apache with CGI in C or C++
    • Apache with leet CGI in Java compiled with GCJ
    • tomcat is a servlet container, designed for running java servlets. Servlets are a type of java application (closer to an application than an applet really...less restrictive security sandbox)
      designed specifically for server applications.

      That's really putting it too simply, but without getting into the details of servlet design...

      • 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?

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close