Open Source 'App Server' comparison on Java World

Discussions

News: Open Source 'App Server' comparison on Java World

  1. JavaWorld has posted "JBoss, Geronimo, or Tomcat? Three open source Java application servers compared," which manages to confuse "application server" with "servlet container," J2EE and Java EE, and - lastly - avoids some major open source containers.
    Java Enterprise Edition (Java EE) application servers are the Web-enabled standard when it comes to application development for the enterprise. While there are commercial options, studies have shown that open source technology has become a familiar, if not essential, part of the corporate IT infrastructure. JBoss 4.2, Geronimo 2, and Tomcat 6 are three widely used open source Java EE servers. Of the three, JBoss and Tomcat hold the majority share of the market, although neither one is fully Java EE compliant. The fully Java EE compliant Geronimo, meanwhile, is quickly gaining momentum. If you want to compete in the Java EE job market, you should be familiar with all three of these open source servers and understand how they differ.
    Of course, the goal is not to compare all open source containers, but focus on three popular ones. However, it's not clear how they determined which containers to look into, or why. When the comparison table uses three different specifications - J2EE 1.4, Java EE 5, and Servlet 2.5 - how is there a common point for comparison? In the feature comparison, some features are shown as "available" when they're not only available, but present. JSF 1.2, for example, is listed as having problems in Tomcat 6 - while the problems exist in Tomcat 5, not Tomcat 6. In addition, he lists JSP 2.5 availability (and presence, for Geronimo) - and that's not even a proposed specification yet.
    Geronimo 2 is the clear choice if your Java application needs are particularly extensive or if you just want to leverage total Java EE 5 compliance. Although JBoss 4.2 is not completely compatible with Sun's Java EE 5 standard, the JBoss 4.2 team is responsible for many of the cutting-edge technologies used by all of the servers and added to the standard Java EE 5 capabilities. Tomcat 6 by itself is a lightweight solution. It does not come with all the JEE features and additional packages found in JBoss and Geronimo, but also doesn't require much memory and runs fast even on smaller servers.
    While Geronimo is certainly a serviceable container (as well as having one of the better administration consoles available), is it actually the "clear choice?" Perhaps JBoss 5 supporters or Glassfish supporters would differ - even using the author's logic, as Glassfish is the reference implementation of Java EE 5, and JBoss 5 is written by the same people who've championed revisions to the J2EE specification that yielded Java EE. It's unfortunate to see JavaWorld not applying more rigorous standards to this article. That said, it'd be interesting to see a better version of this article, including Glassfish, JBoss 5, JOnAS 5, and Resin as well as Geronimo...

    Threaded Messages (60)

  2. Inflammatory[ Go to top ]

    'Deployment issues in SJSAS': which one, is this guy unaware of Glassfish and v.9 and 9.1? I tend to agree with him on the conclusion that Geronimo is the most feature-compliant app server of the 3 chosen, as it (i know this is obvious) pertains to JEE, and it continues to beg the question of where JBoss 5 is at... But the analysis is base-level, and offers very little to readers, other than to push the cause of OSS app servers, which is somewhat commendable... Things I would like to see in a follow-up analysis: ease-of-tool integration/use, clustering ease, web services support, management of app deployment across environment, integration w/ ESBs and BPM, and, generally, something other than just a spec. read-off... The reality is that this report borders on doing a dis-service to every non-IBM shop, at large, and denies the reader an opportunity to comment on the growing trend toward OSS solutions at the JEE level, as it leaves out clear competitors... Overall, though, it is appreciated for its candor on the growing relevance of OSS JEE, and begs some answers from the like of: JBoss - where is v. 5... IBM - when do Geronimo and WebSphere coalesce... BEA/Oracle - how do u build a community of users... Sun - don't let marketing opps. like this go to waste...
  3. The last few years I'm asking myself more and more why we want an application server anyway. Tomcat/Jetty for most application in combination with Spring and a bunch of open source tools works perfect (less bugs, faster, a lot less configuration, ...) than Websphere, Weblogic etc. It is a shame that companies spend loads and loads of money on application servers and not using any interesting functionality. But also not wanting to spend money on software/hardware that really can reduce costs (like a decent grid solution for example).
  4. The last few years I'm asking myself more and more why we want an application server anyway. Tomcat/Jetty for most application in combination with Spring and a bunch of open source tools works perfect (less bugs, faster, a lot less configuration, ...) than Websphere, Weblogic etc.
    To be honest, once you remove money from the equation, I don't see what you gain by taking, say, Tomcat 6, then bolting on a bunch of unrelated products to get an EE-ish application as opposed to deploying GlassFish or JBoss (v5) and just using the standard APIs they ship with. I can't speak for JBoss 5 (I'm unapologetically a GF guy), but installing and configuring GF is pretty brain dead simple, and, if you want clustering, fail-over, etc, GlassFish v2 has that built in, whereas you'll have to jump through many hoops (I'm guessing) to achieve that with Tomcat. I will grant that it's likely that "most" applications may not need a full-blown app server, but, when you do, why use the Frankenstein approach when perfectly viable and (IMO) free, easy to use app servers are staring you in the face?
  5. It depends on the situation. In most cases a simple load balancer and session replication would be more enough to do failover. And most services are stateless anyway. And if I needs to scale out (so a little bit more complicated than session replication), I would rather go for a grid solution than the limited functionality provided by application servers. The only reason why I'm using application servers is that the customer wants them, not because the applications need them.
  6. Think again. Imagine if you are the CTO of American's biggest bank and the solution architect in your bank tells you that they are going to use Tomcat with heavy use of Spring and OpenJMS as modules in Tomcat to run all transactions, are you going to say "Go ahead, hurray Apache!!!"??? When we say enterprise, we really mean enterprise. These open source container can serve the enterprise only when you think seriously. Take a look at support, if you are thinking Geronimo, would you rather spend a bit more money to get a Websphere Express? Websphere isn't that expensive these days and you can still develop your stuff with Eclipse without charges. If you are looking at Sun combinations, seriously I have tried Solaris on x86 dual-core 64bit with JRE 6.0, it's flying!!! So why not getting SJAS? Don't get me wrong, I love Tomcat so much that it is so light weight yet customizable and you can do load-balancing and all that crap with apache brand modules. But when you really think about the business is your property, you wouldn't put these things into your servers easily to have high risks of not having full support; you wouldn't want to browse the mailing-list and forums for answers and when you cannot find one you have to post and wait for the luck. I think one of the best practices to use these open source server is to load them on developer's machine while you have commercial servers loaded in production. But this ONLY applies to companies that have very tight budget. That's where the beauty of JEE coming, abstraction. Your developers can develop and do all unit code testing without messing up the Integration Test Environment and Production and you can save tons of money still. Another way of using these servers are to do some POC (Proof Of Concept) demonstrations before proceeding system architect.
  7. Hard to compare Websphere and Tomcat[ Go to top ]

    I've used both Tomcat and Websphere extensively over the years and honestly, I'd rather use Tomcat any day. WebSphere is a royal pain to use. Once it's all setup and the application is fully tested, WebSphere stays relatively stable. I relatively because I've seen it do all sorts of odd stuff. Using RAD + WebSphere makes software development painfully slow and the minimum system memory requirement is 2GB. Realistically, I would recommend a system with 3-4Gb of memory for daily websphere development. I've also used BEA Weblogic over the years. From my experience, I'd much rather use Tomcat because I can fix a problem myself. I don't need to wait 3-6 months for the company to fix it. Even if you're a huge telco with a full enterprise license, it can still take months to get a patch. This is from first hand experience. I'm sure anyone that has filed a trouble ticket with either IBM or BEA has seen similar response times. If I have 3 months of development left on a project, can I really afford to wait 6 months for a patch from some company? What good is that expensive support? When I found issues in Tomcat, I patched it myself and submitted to bugzilla or jira. frankly I don't buy the enterprise excuse. if it's company policy to only use supported software with "enterprise level support", then by all means pay for it. To equate software quality with paid support just doesn't make sense to me. my bias 2 bits. peter
  8. I don't need to wait 3-6 months for the company to fix it. Even if you're a huge telco with a full enterprise license, it can still take months to get a patch. This is from first hand experience. I'm sure anyone that has filed a trouble ticket with either IBM or BEA has seen similar response times.

    If I have 3 months of development left on a project, can I really afford to wait 6 months for a patch from some company? What good is that expensive support? When I found issues in Tomcat, I patched it myself and submitted to bugzilla or jira.
    I agree absolutely. I would say it is one of the main points, why choose open source solutions. Take a look at Borland Quality Central. Having payed $$$ for Borland development and deployment stuff, you post a bug and have to wait 6 months just to receive "CANNOT REPRODUCE"! Is it the "commercial support" we`ve been told so much about?! And speaking about banks and all of that "enterprise" - yes, they prefer to buy well-known brands. But as they don`t really know anything about it except beautiful words, it is silly to let them decide what your app must be based on. We still use not open source soft in the cases where it performs much better (like CORBA deployment) but try to minimize its use.
  9. Re: Hard to compare Websphere and Tomcat[ Go to top ]

    I guess I said that you have to put yourself into the shoes of the CTO in the bank and having all kinds of pressure from all sides and you probably still choose Tomcat since you don't buy that enterprise shit, but all I see so far is value that I get from what I pay for commercial products; as value I mean the total time and cost of development. Hey, as I said, don't get me wrong, if I run my own business I will definitely get Geronimo as ESB backbone and having Tomcat with Liferay deployed as thin-client and install db4o as transactional database, how's this open source combo? I like it if I don't have money, but if I do I will pay for something that I don't have to invest for risk. People can solve problems and build something missing from open source solutions just because they work longer hours to work something out and fill the gap, which doesn't necessary mean that the open source products are meeting the expectations and you have consider those smart people are lucky enough that the management is not very demanding in terms of change. Smart people are almost the keys but we are solely talking about the products themselves in this thread. Let's go back to the topic, like above, I would architect in the way of having Geronimo or Glassfish as ESB backbone and Tomcat with Liferay deployed as frontend development so I have all collaborations, BPM and other aspects in one place.
  10. I have worked with Weblogic and WebSphere over the years. My bias experience will tell you that the enterprise support sometimes doesn't mean much. They will provide the most basic support pretty quickly (such as how-to-do-this type of questions). This could be helpful if you are dealing with new technology or product just of coming out and there are not much you can find out on the web. But if you are dealing with bugs or fixes, you are out of luck. WebSphere is a real pain to work with. Once we have to port an application (EJB2.x) to WebSphere 5. We have to start to use RAD tools. There were three choices of porting: top-down (develop EJB and generate database schema) or bottom up (from database to EJB) or meet-in-the-middle. Since we have already have the EJB and Database Schema and code worked fine in JBOSS 4 and WebLogic 8.1; we can only use meet in the middle approach. Except that meet-in-the-middle doesn't work. As through no one has worked on it. I flew to Austin, TX to meet IBM architect who spent a week and still couldn't get the basic code functioning. Eventually, we have to re-write the entire EJB2.x code in Hibernate to make it work in WebSphere. The time spent in rewriting is less than the time we previous time spent tried to port to WebSphere. Weblogic is much better, I actually like to work with Weblogic. Out of three application servers: WebSphere, Jboss,and Weblogic, I like weblogic the best. But Weblogic support is also pretty much worthless, you can get more information on the dev2dev user groups without paying for anything. I recently worked on the Weblogic 10.0 and find several bugs. One bug I actually got a patch after 4 months (to be fair, it was actually an OpenJPA bug, they have to wait for the patch from OpenJPA) . It takes many-many-emails with a self-container sample code and unit test and database schema and two months to convince 2-3 level of support that this is a bug. Another bug I reported to BEA was changed hands 4 times. The first support was telling me that he can't repeat the problem. I ask him did you run the complete sample code I sent to BEA he said no, because he can only run Junit not TestNG. I told him all he all he need to download TestNg jar file and type ant run-test. That silences him; then cames the 2nd supporter after few weeks; and claiming he was able to repeat the problem and problem is in "XXX.java"; I told him that's Apache's code, he promise to investigate; then comes the 3rd support and ask me how to download Javaee.java and testng jar, I told him that he supposed to be an EJB3 support engineer, and he should know these stuff. Then the last engineer comes back again see she couldn't repeat it again, seem have no knowledge of previous conversations in last 4 months. I eventually stop sending bugs to BEA support as it only waste my time responding emails to support with no resolutions. The new version Weblogic 10.3TP actually fixed many of the bugs I experienced before. Your experience could be different. But enterprise support sometime doesn't mean much unless you can get access directly to the developer, even in that case the result could be vary depending on product. my 2 cents. Chester
  11. I have worked with Weblogic and WebSphere over the years.

    But if you are dealing with bugs or fixes, you are out of luck.
    One multi-billion dollar company I worked with had been pleading with IBM for months for help getting Log4J configured with WebSphere. Another huge company bought the entire IBM package; hardware, WebSphere, DB2 and was floundering over getting a basic setup working. I supported both WebLogic and JBoss for almost a year. When it was time to renew the WebLogic license we let it expire because we weren't getting anything from their support we couldn't get from JBoss.
  12. Think again. Imagine if you are the CTO of American's biggest bank and the solution architect in your bank tells you that they are going to use Tomcat with heavy use of Spring and OpenJMS as modules in Tomcat to run all transactions, are you going to say "Go ahead, hurray Apache!!!"???
    Several of the biggest banks in the world do use Tomcat plus Spring extensively, and they don't pay for support for it. Why would they? Tomcat (following the Apache model) is far from beautiful, but (following the Apache model) is generally stable. Spring works. For a decent portion of the apps they need, the combination suffices. Peace, Cameron Purdy Oracle Coherence: The Java Data Grid
  13. Think again. Imagine if you are the CTO of American's biggest bank and the solution architect in your bank tells you that they are going to use Tomcat with heavy use of Spring and OpenJMS as modules in Tomcat to run all transactions, are you going to say "Go ahead, hurray Apache!!!"???
    Believe it or not, but large financial organizations are actually moving away from Websphere towards Jetty because they are more cost-effective that way. It is do to with turnaround times, ease of testing and the transparency of the application environment. How many months before Websphere became JDK5 compliant? So yes, CTOs actually "get it". At least some of them do. My personal opinion is that the ones clinging to a vendor to prop up their development are bound to fail. There is no money in application servers any more, and the support you get is going to reflect that. Geir
  14. Believe it or not, but large financial organizations are actually moving away from Websphere towards Jetty because they are more cost-effective that way. It is do to with turnaround times, ease of testing and the transparency of the application environment.
    I sincerely don't believe it because I am working in the bank and I did say my words after I've done some research for other banks as well. But I don't want to argue to the point of how business runs because this is not the topic for it although the software we are talking about are business driven.
  15. How many months before Websphere became JDK5 compliant?
    Heh, my question is: how many more months before it becomes JEE5 compliant? Hard to say who was more embarrassed when the JEE5 app I developed using Glassfish wouldn't work on WAS 6.1 — me, for not doing my homework, or our WAS admin, who had heartily assured me that WAS 6.1 was state-of-the-art, so I could use whatever new JEE features I wanted... (I don't think he even had a Java 5 JDK installed, just the JRE.)
  16. (I don't think he even had a Java 5 JDK installed, just the JRE.)
    It's not a good practice anyway of using the JDK at runtime...
  17. State of the art huh? Lots of shops are still running WAS 5.1.X.X. You'd be lucky to find WebSphere Shops running JDK 1.5 (because it's only supported under WAS 6.1 and above). So you'll have fun working with J2EE 1.3 API's, and JDK 1.4.
  18. Think again. Imagine if you are the CTO of American's biggest bank and the solution architect in your bank tells you that they are going to use Tomcat with heavy use of Spring and OpenJMS as modules in Tomcat to run all transactions, are you going to say "Go ahead, hurray Apache!!!"???
    As Cameron pointed out, most large banks use Spring extensively. I'm writing this from the Spring Experience conference in Florida, where yesterday a senior architect from HSBC talked about how all their Java applications will soon be using Spring. In 2006 (the most recent data I can find) HSBC was ranked #1 in world banking groups by assets and #2 by market cap. Also, the best Apache projects are used heavily in the enterprise--including in many commercial products. Certainly Tomcat use is a minority in large banks, but it is growing. I know of some examples. HSBC are also a SpringSource support customer, and their decision process showed that purchasing a support contract lowered their costs as well as giving them peace of mind. Certainly the availability of commercial support helps promote enterprise adoption of open source, and is healthy for the open source ecosystem.
  19. Think again. Imagine if you are the CTO of American's biggest bank and the solution architect in your bank tells you that they are going to use Tomcat with heavy use of Spring and OpenJMS as modules in Tomcat to run all transactions, are you going to say "Go ahead, hurray Apache!!!"???
    I was once IT manager in a Bank with mere 300 branches. I agree with you completely. I would choose BEA or IBM not because they are good, mostly to safeguard myself. If you choose a very good open source software (like Tomcat) if you come to a serious problem (which might be totally independent from Tomcat), everyone will criticize you of choosing open source unsupported products. If you choose BEA or IBM you can easily tell these are the leaders of Market and if this bad thing has happened with them, it would happen more with smaller or less supported products. In IT manager position you become more conservative even though in technical life you are a very open minded person!
  20. Think again. Imagine if you are the CTO of American's biggest bank and the solution architect in your bank tells you that they are going to use Tomcat with heavy use of Spring and OpenJMS as modules in Tomcat to run all transactions, are you going to say "Go ahead, hurray Apache!!!"???


    I was once IT manager in a Bank with mere 300 branches. I agree with you completely. I would choose BEA or IBM not because they are good, mostly to safeguard myself. If you choose a very good open source software (like Tomcat) if you come to a serious problem (which might be totally independent from Tomcat), everyone will criticize you of choosing open source unsupported products. If you choose BEA or IBM you can easily tell these are the leaders of Market and if this bad thing has happened with them, it would happen more with smaller or less supported products.

    In IT manager position you become more conservative even though in technical life you are a very open minded person!
    Thank god, someone finally understands what I am saying. I guess these people are too much of a developer, no offense, sorry, I just mean that we should try to look at things in different perspective. HSBC has a culture of rocket-fast development with minimal resource given to minimize development cost and try to get high return. Yes it's one of the largest banks in the world but it doesn't mean the management in IT is making the right choice. In the long term, it could be a serious problem because this is not only a technical problem, it would be also operational and political problems (like people start pointing fingers when the appserver fails or migration to new version takes longer than expected). If you look at appserver as a product simply like investment product in management perspective, the keyword here is: Risk and this results to something Siamak mentioned (very well mentioned, thank you): conservative. And he's right, I am very open minded person to use all open source products in my own development but once it goes into production, you can have only zero-tolerance to make you look good and successful.
  21. Andy
    HSBC has a culture of rocket-fast development with minimal resource given to minimize development cost and try to get high return. Yes it's one of the largest banks in the world but it doesn't mean the management in IT is making the right choice. In the long term, it could be a serious problem because this is not only a technical problem, it would be also operational and political problems (like people start pointing fingers when the appserver fails or migration to new version takes longer than expected).
    We also had presentations at the conference about extensive use of Spring (also mentioning other open source) at Morgan Stanley and Barclays Global Investors, not to mention Fedex and Orbitz. At last year's European SpringOne conference we heard from the IT Director of Voca, who do all UK interbank payments (for the world's 4th largest economy) making heavy use of Spring (and some other open source). 9 out of the largest banks in the world are not merely Spring users but SpringSource customers. John Rymer of Forrester Research also gave an interesting keynote about how open source is influencing customer decisions and the implications for the large vendors. The IBMs, Oracles and BEAs of the world remain important, but with the proven high quality of the best open source solutions and the availability of dependable commercial support open source is gaining in many categories and offering real user benefit. Rgds Rod
  22. Ron, I agree with you and I have never said that open source SHOULD not be used in enterprise and in fact there are many projects implementing systems using open source libraries. Take a look at how many enterprise level projects using Log4j and you know ;). But I am trying to talk about the use of open source. It's not necessary that you cannot use them in production, it's just the fact that you would not want to put your company at risk when you implement something that is mission critical. Again, I am not saying open source is not reliable. I implemented Liferay, open source portal, in my previous company as portal and developed portlets myself to communicate using Apache Axis 1.3 with web services application that I developed using Eclipse in which it was deployed on Geronimo. Then I also created blackberry applications to talk to these web services so you can query information from AS/400 on your blackberry in real-time using all these open source techniques that didn't even take me 1 month to finish the SDLC. I have the guts to put it working in bank's production, but can I? people are conservative there that even you prove them "it's 200%" working flawlessly, would they do that? You only give them confidence that you are a good developer and these products are good to have ONLY when they are included into commercial products. Take a look at the business model from IBM, Oracle and others that have open source projects supporting the R&D of their commercial products. They know that all these open source are "cool", so they wrap them into commercial products. Why they are making big money from these commercial if people are going for all open source? Take away Websphere or RAD from all my previous comments if you don't like them, try the following: How about taking Liferay core, wrap it with some features that your competitors do not have and customers need to pay for these?
  23. I will grant that it's likely that "most" applications may not need a full-blown app server, but, when you do, why use the Frankenstein approach when perfectly viable and (IMO) free, easy to use app servers are staring you in the face?
    I couldn't agree more and have actually seen that practice a lot: projects start just based on Tomcat, with the motivation that it should stay agile, fast and not bloated. So far so good. Then, one of the first things they nowadays add is JSF. Soon after some JPA implementation will be added. If the shop is serious about their business, they'll probably need transactions too, so a JTA implementation is next. Of course, there's probably a need to send emails at some point of time, so the activation and mail jars are added as well. Next to that, the project probably needs some other libraries too. Before you can blink with your eyes, you suddenly find that your project is bundling a ton of extra jar files from separate locations. Each 'service' you add doesn't simply come as a single jar file. Far from that. Something like 10 jars for JTA (JOTM), another 10 orso for JPA (Hibernate), at least two for JSF (Sun RI), etc. Now -you- have to keep track of which jar file belongs to which 'service' you added and what version it needs of the dependent jar files. You also need to track the several locations where all that stuff came from. In a way, you may compare this with creating your own Linux distribution from all individual parts out there. Sure, it can be done, but simply taking a ready to use distribution where all the individual parts have been tested to work together and where the entire system can be updated as a whole is just so much more convenient.
  24. Yes, sometimes the question should be put the other way: why not using an application server? If your application is an enterprise application, you might start small, but eventually you will have to face some common challenges like scalability and security. I am sure that the same application can done with say, JBoss as an app server, or with Tomcat + Spring. For me the issue is, which one is going to be easier to develop? which on will give me less headaches? which one will be easier to staff? I think that the 'build your own app server' approach (tomcat + Spring in the example), will require more knowledgeable developers, which are harder to find. Going back to the original article ... very disappointing. Not worth reading. Regards, Paul Casal Sr Developer - jBilling The Enterprise Open Source Billing System
  25. ... For me the issue is, which one is going to be easier to develop? which on will give me less headaches? which one will be easier to staff?
    I think the easiest development approach is based upon the combination Tomcat+Spring not using EJB. The point is that Spring is easy to understand , integrate , test and use. The EJBs are not: you have to face with problems that are not relevant for your business.
    I think that the 'build your own app server' approach (tomcat + Spring in the example), will require more knowledgeable developers, which are harder to find.
    Not "developers", but "knowledgeable java architects"! A developer develops what you ask him/her to develop.
  26. I think fewer and fewer people are using EJB now, so why I need an application server. I also feel frustruted by the author who doesn't understand what's difference between application server and servlet container. How come Java World publish this kind of article which will confuse the beginner of j2ee.
  27. Is it fewer and fewer, I don't know. But my company and our competitors are all using it everyday and in the coming couple of years they are not thinking to take it away. But I definitely second your point there that the author doesn't even know what he's talking about.
  28. I wouldn't be surprised that there will be an uptake in the overall use of EJB technology in EE versions (to come). Not because it's 'cooler', but because it's easier and transparently uses container services.
  29. The last few years I'm asking myself more and more why we want an application server anyway. Tomcat/Jetty for most application in combination with Spring and a bunch of open source tools works perfect
    Tomcat and Jetty are application servers
  30. In my opinion they are Servlet containers. Application servers also have support for EJB, JMS etc, so they provide a lot more functionality than 'simple' servlet containers.
  31. Q: Tomcat[ Go to top ]

    Who does priority support 4 running Tomcat in deployment scenario/environment? IBM is not the answer, as they will move their customers to Geronimo before Tomcat...BEA and JBoss may embed it, or at least previous versions do, but can Tomcat clustering be delivered by their support org.'s.... An application server is more than just a development platform, it is a run-time and an ecosystem, and customers depend on vendors to build their software suites around them, can this be said ab/ Tomcat, as it stands alone?... Without getting in to an EJB debate, one can make an argument that Tomcat is not enterprise-capable for a number of reasons, though it is a safe choice for JEE beginners, it will not be on the short-list of deployment containers, as it does not provide a reliable path for support... I can understand that it provides an upgrade path to JEE, but as has been said in a previous post, why not go with Glassfish, Geronimo, or JBoss, which are all free at the level of support that Tomcat provides, and they provide upgrade paths to enhanced functionality, etc..., though Geronimo needs to clarify its path to WebSphere in a more coherent way.... In short, Tomcat is not an application server, sorry to begin the flame war...
  32. Re: Q: Tomcat[ Go to top ]

    I once talked with developers from Netflix at a symposium - it's my understanding that the world-famous Netflix site / system is running on Tomcat so this statement:
    Without getting in to an EJB debate, one can make an argument that Tomcat is not enterprise-capable for a number of reasons, though it is a safe choice for JEE beginners, it will not be on the short-list of deployment containers, as it does not provide a reliable path for support...
    is not accurate with respect to enterprise-capable. I don't think any enterprise succeeds merely by virtue of an application server choice (including its support model); rather, an enterprise usually succeeds based on skill with which a particular platform is wielded. Thus, if you're a guru at configuring a tomcat-based platform for extreme deployment purposes then that's fine by me. One other comment on aspects of this post; I've attempted to use support channels from JBoss, BEA, Websphere, etc. over the years for various issues. My experience is that you're just as likely (if not more) to find a solution to a technical problem using Google as you are by contacting your vendor support channel. This final statement
    In short, Tomcat is not an application server, sorry to begin the flame war...
    merely reflects your own personal limitations on this subject.
  33. Support Contracts[ Go to top ]

    They are a waste of money, novices hired for their cost, not their technical or communications skills. Besides JBoss uses Tomcat but just makes the thing a whole lot more complicated and takes away the nice console that Tomcat in exchange for dubious enhancements such as an EJB container.
  34. I agree with Elmira[ Go to top ]

    I prefer Tomcat for its robustness and simplicity. Support contracts are pointless except as a way to fund development (what we used to pay licensing costs for)
  35. easy, Brad[ Go to top ]

    You did not address the question of Tomcat's availability for issues that you cannot solve on google.com, I believe there is an org. or 2 that does Tomcat support on its own, I remember reading about it, so there is some channels to use, but I find it difficult to believe that Netflix relies on your supposedly tried-and-true method of searching public documents via a search engine... I have long argued, that a web server, which does have servlet functionality, is not an application server, and I tried to hide my own bias toward EJBs in that response; it is just not possible to do an apples to apples comparison when you consider the marketing, sales, support, pricing, and development models that assume Tomcat as an application server... I apologized for prompting your response in my original post, but I think that others on this thread have succinctly argued as to why it is limiting bordering on pointless to utilize Tomcat as an application server platform, I would suggest, though you don't have to take it, that you keep your personal attacks to something that is not being backed up...
  36. Colavent[ Go to top ]

    Geronimo and Jboss both use tomcat. Covalent will gladly take your money, if you want enterprise level support. If you look a the code base for glassfish and tomcat, I think you'll find a lot of similarities. If Glassfish is enterprise ready, then by definition, so is tomcat. Just my bias opinion. but whether a particular servlet container is stable and robust, is not dependent on a company providing support. It should be judged by the code and how it performs. I know of several websites using Tomcat that handle 10million+ page views a day.
  37. Tomcat Rules![ Go to top ]

    Support contracts for open source projects are nothing more or less than a checklist item used by those who make the policy decisions based on what sounds good to senior managers. Unfortunately this leaves no money to develop open source for a living unless you can make a living on contracting and consulting but not the project directly.
  38. I can describe the case for Sun and GlassFish. One of the main value propositions of what Sun provides are fully qualified sustaining releases that have _only_ bug fixes with minimal stability disruption for a long (5 yrs is typical) period of time. This means the customer can safely upgrade to the latest 'sustaining' release whenever he/she wants to. Not when the next public release is available, which may include also new features - and new bugs. Another value proposition are quaranteed responses. Not all customers will need these type of services, but some, like large enterprise customers, do. They cannot afford to suddenly discover a new bug and then being told "updgrade to the next public release", or "sorry, we don't have a stable build ready". Or upgrade and then discover something has stopped working because of some subtle change. And before people jump into it, in the case of GlassFish/SJS AS all bug fixes that go into the sustaining releases also go into the public releases. The difference is that _only_ a few, _highly controlled_ bug fixes go into the sustaining releases. See [1], [2] and other posts at [3] [1]http://blogs.sun.com/alexismp/entry/support_for_glassfish_what_s [2]http://blogs.sun.com/pelegri/entry/hardening_productizing_open_source_projects [3]http://blogs.sun.com/theaquarium
  39. Tomcat/GlassFish Web Tier[ Go to top ]

    If you look a the code base for glassfish and tomcat, I think you'll find a lot of similarities.
    That is correct.
    If Glassfish is enterprise ready, then by definition, so is tomcat.
    But this does not follow. I'm not going to argue against Tomcat as there are many happy Tomcat customers. But GlassFish forked from Tomcat a while ago because Tomcat kept doing changes (small and large) that would break our functionality and it became harder and more expensive for us to deliver what our enterprise customers wanted while Tomcat kept changing.
  40. In my opinion they are Servlet containers. Application servers also have support for EJB, JMS etc, so they provide a lot more functionality than 'simple' servlet containers.
    Well, Jetty 6 comes nicely integrated with much of useful JEE stuff (including JTA, JNDI, JMX and other commonly needed pieces). Only bigger piece missing is EJB, and that's pretty much just good riddance. It is also easy to weed out parts you don't care if you prefer simplicity. And plugging in similar components to Tomcat is rather easy, and unlikely to cause major headaches. This because Tomcat interoperability is probably more important for most open source projects than, say, commerical app server interoperability. There is certainly something to say for integrated platforms where components are tested to interoperate well. But for majority of uses, developers would do well to use right-size solution, not just settle for a kitchen-sink-too alternatives.
  41. You're confusing Application server with EJB container. While Tomcat contains a Servlet Container, it actually has more features, and in fact, you can develop applications to be served by it.
  42. Coming in late here... First off, just to get this out of the way, the article is complete crap. I don't blame the author, I blame the editors. They should know better than to publish an article this bad. I think that Tomcat, RAW Tomcat, is not an "application server". While in truth that definition gets muddier everyday, and applications can be built on raw Tomcat, out of the box I don't think that it meets the more formal definition of what folks today consider an application server. If you think the the Servlet API, JDBC, and JNDI support are all that are required for an app server, then I guess we'll have to agree to disagree. However, projects like Spring, or the assorted OSS components like JTA and JPA implementations, allow Tomcat to become an application server, even if, perhaps, an informal one. But performing a bullet point comparison between Tomcat + libraries and a full boat JEE app server, and you'll see a lot of commonality. Putting compliance with formal industry standards aside as a potential software stack requirement, the primary difference between a JEE server and a Tomcat + libs tool set is basically the difference between folks who may like NetBeans vs Eclipse or BSD vs Linux. A primary benefit, IMHO, of NetBeans, is simply the Out Of Box experience. Download it, one-click install it, and launch it, and the full stack of common (albeit Sun/JEE centric) environments is there. No scrounging around for plug-ins or patches. If you want to do modern JEE development, it's a 10 minute process with a good internet connection to get going. Eclipse take the more toolkit approach of supplying an underlying framework upon which you can build the IDE that you desire. But that extra functionality is scattered and you need to forage to get it. Same with BSD. Download FreeBSD and you get a single kernel and userland; built, maintained, and distributed as a whole. When you say, offhand, that you run "FreeBSD 6.x", everyone "knows" what that means. With Linux, you need to qualify your kernel, your distro, etc. etc. Many of the modern Linux distros solve the "out of box" experience for Linux, but when solving problems, "running Linux" is simply not enough information. The app servers provide the "out of box" experience, where you get a complete set of functionality all built, maintained, and packaged together as a whole. With Tomcat and libraries approach, it's more of a build it as you go. The two styles appeal to different people. I'm of the NB/AppServer/BSD persuasion. I'd rather start with a whole and disable portions if required than build up the bits and pieces and integrate them my self. Frankly, today, thinking I won't need all of the JEE services is a form or pre-mature optimization. To be fair, there are projects that do much of the grunt work for you, pre-bundling Tomcat with other project libraries. But you still have the balkanized system to support. If you have a question, you need to go to the pertinent technologies community to search out the answer, for example. With Glassfish, as an example, if you have a JPA issue, go to the Glassfish forum. EJB issue, Glassfish forum. Servlets, web services, JMS issue? Glassfish forum. Note forum singular, traffic hasn't grown enough to necessitate splitting it up in to specific areas. That's a really good support experience, as the whole cross section of folks working on the project intersect on the GF user forum/mailing list. In my experience, the GF forum has been very responsive. There are few unanswered questions on it. I also get good response from the Tomcat mailing list when I used it heavily. But, as an example, I had less luck with Jetty's mailing list. Many of my questions fell on deaf ears. Neither GF nor Tomcat/Spring are trivial pieces of software. They both have their gremlins and complexities. I will say that modern EJB development on top of GF with EJB3 is a dream, it pretty much "just works", and exposes the complexities only as you start running in to the implicit limitations that using the default, convention-over-configuration, and annotations require. But so far, it's been able to take pretty much everything we've thrown at it. GFv3 is going to be even better, and in fact narrow the gap between Tomcat + Libs and an App Server with its modular architecture. Enabling to you to have much finer control over what your full deployed application + infrastructure footprint will be. And from what I hear of JEE6, the distinction will simply be matters of vocabulary between the two camps, but the model essentially the same. But, again, with the App server approach, with both GF and JBoss, you get to start with the whole and whittle down as necessary vs start and the bottom and build up. *I* am more comfortable with the former than the latter, and I whole heartedly recommend GF to all comers. It's becoming a cake and standards too world, combinined with single source support and an overall easier to use process with modern GF.
  43. The last few years I'm asking myself more and more why we want an application server anyway. Tomcat/Jetty for most application in combination with Spring and a bunch of open source tools works perfect


    Tomcat and Jetty are application servers
    Tomcat and Jetty are not application servers. They are servlet containers that you an use with some application servers. The do not provide the resouce management, transaction management, and clustering support of a true application server. I am not even talking about EJB3 as you can us JPA on a servlet container. But when you do that you give up the robust transaction management that you get in say a Glassfish. =========================================== This Article was lame at best and pure marketing for Geronimo and JBoss. Glassfish is fully JEE 5 compliant and is being used by at least as many companies as Geronimo. As for JBoss, they have stagnated at the older version of the JEE spec. see http://weblogs.java.net/blog/kalali/archive/2007/12/four_open_sourc.html for a review of Glassfish.
  44. In most applications you only need to do transactions over a single transactional resource at a time. In those cases a standard transaction manager is good and fast. And SpringAspectJ can be used to wrap transactions around the location where needed. With the introduction of Spring and various other technologies, a lot of responsibilities the application server used to take care of, are now being provided by tooling of choice. And clustering support like a true application server? That is a bold statement. I would rather spend my money on a proven grid solution like Gigaspaces, Terracotta, Coherence etc. And for session replication there are many lightweight solutions available. I like the have the choice of which technologies are being used. Unfortunately this isn't always the case and leads slower development.
  45. The last few years I'm asking myself more and more why we want an application server anyway.
    JTA. Say you want to do JMS and JPA stuff on same transaction. No?
  46. jta alternatives[ Go to top ]

    I wonder what the future of the appserver is, given the fact spring + jpa (hibernate) gives one nearly everything the appserver was supposed to provide, with a lot less complexity, and easier testability. Where I work websphere is nothing more than an expensive connection pool... (which c3po probably does better :) ) Time Passx- check out atomikos if you need XA without the appserver.
  47. Re: jta alternatives[ Go to top ]

    I wonder what the future of the appserver is, given the fact spring + jpa (hibernate) gives one nearly everything the appserver was supposed to provide, with a lot less complexity, and easier testability. Where I work websphere is nothing more than an expensive connection pool... (which c3po probably does better :) )

    Time Passx-
    check out atomikos if you need XA without the appserver.
    In my test env I am able to run a J2SE app with: 1. JOTM 2. Atomikos 3. JBOSSTM (ArjunaTS) 4. JBOSS Transaction all perfectly configured in JNDI. It isn't that hard to do the same in Tomcat. I know that enterprise managers don't like this way of assembling things. Unfortunately, they are not the one who pay for their choices. Guido
  48. Lots of people still care about operational model that comes to table with app servers.... crazy people! who cares about that nowadays, specially when developers don't. Please Sun don't give away java to developers control..
  49. TheServerSide is a fantastic site to quickly put a finger on the pulse of the industry. However, the application server matrix you provide has not been updated since March 27, 2005. Having this matrix updated would be a tremendous benefit to those of us who have to quickly make decisions on our operating environments. What do you think? It would be a great Christmas present! Thank you!
  50. To me software comparison is not about the features (unless I really need them). It is more about community, support and resource availability (developers who are familiar with the product, documentation, etc). I cannot talk about Geronimo support, commercial or otherwise. I met the developers at the ApacheCon. They seemed very nice and responsive. So, I am assuming that community around Geronimo is the same way. Now, I do not think resource availability is there, but I think it will change overtime. I never sought support for Tomcat, but its ubiquitous nature makes it easy to get help and there are plenty resources available for it. Now, I have a special place in my heart for JBoss. At some point I bought support for it. The most expensive I could find at the time. It was before they were bought by Red Hat and switched to a very complicated pricing model that offered an equivalent support to what I had three times the price. Without any exaggeration I could say it was useless. Anytime I would have a question, I would get asked 10 in return. Then they would request for me to create stand along example together with the unit test and send it to them showing the problem instead of looking at the problem in its context. They would also request I recreate a problem just using their technologies. In other words if I was using Spring I had to strip it out. Then they would finally say that they could not figure it out because it is most likely Spring issue. In other words absolutely useless. In terms of community it is certainly large, but some of the JBoss employees have a nasty attitude. Like Gavin King calling people lazy, what the hell is that anyway? This was before I met Gavin in person, when he was trying to sell JBoss Monitoring and spend 15 min bashing Spring and Dependency Injection to the audience that was predominantly using Spring. Or Red Hat sending cease and desist letters. So, I am seriously thinking giving Geronimo a try.
  51. Having worked with WAS5,6,6.1/Tomcat5.5/WPS5.1/6 for years at a high volume/transactional level my comment on the thread here is: "Dont expect the AppServer to solve your coding/knowledge problems". We should not expect the AppServer choice to enable us to easily solve problems that are fundamental to the technology platform (eg, classloaders, concurrency, thread safety, memory leaks, memory fragmentation, garbage collection, excessively chatty interfaces, transactional integrity problems, inflexible deployment etc..). While a poor appserver implementation will exacerbate these issues, by far, in my experience, the biggest issues have been a) poor implementation (eg, lets have 20,000 lines of spring config, with every bean a singleton, with no re-entrant code). b) poor understanding of the specification (eg why do we need resource references ??) c) poor understanding of the platform (why is parent_last important for WAS) While we can moan about support (existant or non-existant) for the commercial products or open source, they will never solve a, b or c. To me there are 2 issues 1 - Organizational - Enterprise Architecture standards (J2EE 1.4, vs J2EE5) where the "compliance" of the server is important.When choosing an AppServer, has all sorts of management and operational issues. What is seems to be forgotten is that the app will eventually (we hope) make it into a production environment and be maintained, upgraded and managed for a number of years. 2 - Development/Implementation - guided by 1, and this is where the "learnings" of a new technology happens (or should). While Servers like WAS have a learning curve, the key here is people. Get/find/consult with guys that a) know J2EE best practise back to front. That sleep with the Specs under their pillow. Capable of critical appraisal and really know the weaknesses, strengths and ambiguities of a spec. b) really strong at aligning requirements(functional, non-functional and architectural) to implementation. Can recognise over-engineering as scope creep, and has the customer's interest at heart and not just driven by RDD (resume driven development). c) Once a app server is chosen, get people who have a deep technical knowledge of the app server implementation. just my 2c
  52. Daring to be Different[ Go to top ]

    Having worked with WAS5,6,6.1/Tomcat5.5/WPS5.1/6 for years at a high volume/transactional level my comment on the thread here is:
    "Dont expect the AppServer to solve your coding/knowledge problems".
    +1. Hi Micheal, This discussion takes me back to 2002 the latest, but in 2007 it's sounds positively arcane :^). Hibernate and Spring have shown that Java the language is more important than J2EE the platform. And as a result many have chosen to dismember the J2EE "Elephant" and only consume the bits they actually need. Taking Bruce Tate's lead after his "J2EE Elephant Article", many began looking more closely at the lack of core abstraction features in the Java language and what to do about it. IoC frameworks like Spring and the CGLIB library upon which Hibernate is built, are a direct response to limits in the Java language. Many have moved on to alternative languages like Ruby and the Rails framework that make much better use of OO abstraction, and others are loking at C# language which now makes use of functional programming concepts, bringing new approaches to enterprise programming like LINQ. There are other interesting alternative languages out there too like Scala, Erlang and the href="Boo" rel="nofollow">http://boo.codehaus.org/">Boo language which was brought to my attention only recently. There was a recent discussion on TSS about Java and Computer Science. IMO the Java industry with all its vendor driven "standards" has come be mostly about products and product marketing and has little to do with CS. Some companies have totally bought into this "align yourself with a vendor and run with the herd" mentality whilst others dare to be different. It will be interesting to see which 'attitude' prospers the most in the future. Paul.
  53. Re: Daring to be Different[ Go to top ]

    Paul
    There was a recent discussion on TSS about Java and Computer Science. IMO the Java industry with all its vendor driven "standards" has come be mostly about products and product marketing and has little to do with CS.
    I agree, although I think the trend is for things to get better rather than worse. Rgds Rod
  54. Re: Daring to be Different[ Go to top ]

    Paul
    There was a recent discussion on TSS about Java and Computer Science. IMO the Java industry with all its vendor driven "standards" has come be mostly about products and product marketing and has little to do with CS.

    I agree, although I think the trend is for things to get better rather than worse.
    Rgds
    Rod
    Hi Rod, I hope your right. Personally I'm looking elsewhere like at Ruby and Rails. I read your blog post on JEE6 an there is reason for optimism: http://blog.interface21.com/main/2007/07/03/java-ee-6-gets-it-right/ What Java/JEE needs is an opinionated voice willing to say it as it is. Is interface21 that voice? I don't know, but from your writing on your blog you definitely sounds as though you'll do a better job "on the inside" then the guys from JBoss :^). I think the problem is more fundamental then JEE. The problem is the language. Java as a language is what it is, and it has always been a blunt instrument. Mostly because of Gosling insisting that the children would hurt themselves if they were given something sharp to play with :^). The pedestrian pace of change in the core Java language means that it is unlikely to catch up with sharper alternatives like Ruby or even C# any time soon. And recent changes (Java 1.5) tend to indicate that Sun just don't get it. Many things in Spring have relied on new language features such as the dynamic proxy API. As it stands things like Open Classes and Mixins aren't even on the radar for Java and functions as first class objects (closures) are still in the distance with Java 1.7. So a weak object model (classs are not objects), no late-binding (message sends), weak Meta-programming and no functional programming. These programming features have been around for decades, yet Java excludes their use. As I mentioned before take a look at Boo. It shows just how much is possible, and how much Java is lacking. Paul.
  55. Re: Daring to be Different[ Go to top ]

    Sorry. A working link this time :^)
    As I mentioned before take a look at Boo. It shows just how much is possible, and how much Java is lacking.

    Paul.
  56. Re: Daring to be Different[ Go to top ]

    Hi Rod, Sorry for responding to my own post, but I just had an idea. Interface21 could really provide a lead by utilising JRuby to add many of the language features to the JEE platform I describe above. So a Spring release with JRuby integration would be a massive step in the right direction: * Bean wiring using JRuby instead of XML * Integrating ActiveRecord with Hibernate. * LINQ implemented in JRuby and integrated into JDBC * ... If interface21 came out with something like this it would be a massive step forward, and it would throw JEE back into contention with Rails and .Net. It would also provide real leadership for the Java community IMO. Paul.
  57. Resin is open source[ Go to top ]

    And this 03 study says it's popular. http://news.netcraft.com/archives/2003/04/10/java_servlet_engines.html .V
  58. You can't beat the Glassfish + Netbeans combination. No one uses Geronimo and JBOSS is losing customers to Sun.
  59. You can't beat the Glassfish + Netbeans combination. No one uses Geronimo and JBOSS is losing customers to Sun.
    I'm not so sure about the Geronimo and JBoss statement but I do agree that the NetBeans/GlassFish integration is pretty damn amazing. I was really blown away with the ease of use when working with the two.
  60. A J2ee container has two sections. One section deals with Servlets and JSP while the other section deals with other technologies like JMS,JNDI,EJB,Connector etc. Tomcat is fine as a Webserver( servlet/jsp compliant) but App servers proper are Jboss and GlassFish. I would suggest that we use Tomcat for web-tier and either Jboss or GlassFish for the more adavanced j2ee services. Both are open-source and free. If more and more users adaopt these two, we can say goodbye to IBM's websphere and BEA Weblogic. Why not? And Tomcat and JBoss/Glassfish teams should provide a lot of simple tutorials and demos for learners and make them popular.
  61. Reading this thread, I'm more and more convinced that we did the right choices for JOnAS 5, the OW2 open source application server, that unfortunately was not mentionned in this article. JOnAS 4 was a J2EE 1.4 certified open source application. JOnAS 5 first release candidate has just been released last week. It adopts a brand new dynamic services architecture, natively based on OSGi. This provides the following advantages: - the application server is modular and dynamically adaptable to the application needs, i.e. if you only need a web container, it will only start the corresponding technical service (and the services it depends on) - it is delivered with EasyBeans, a lightweight EJB3 container, that may also be used in standalone or with Tomcat or Jetty only. - different services implementation can be chosen, e.g. Tomcat or Jetty for the web container, Hibernate, OpenJPA and so on for the JPA implementation ... - it is ready for Java EE 6 profiles, when users do not need the complete Java EE support but only a subset of it. Moreover, refering to the article comparison table, JOnAS 5 already supports EJB3, JSP 2.1, Servlet 2.5, JSF 1.2, clustering, Eclipse IDE connector (WTP), Hibernate native usage, and Java EE 5 compliance will be completed in the next release.