Why is JBoss at the Bottom of this List???

Discussions

News: Why is JBoss at the Bottom of this List???

  1. Replay Solutions recently surveyed 1000 enterprise Java professionals, and when they asked them which application servers they were going to be using for testing and deployment, only 18% chose JBoss. Am I missing something here?

    "Java EE App Servers: 50% of respondents chose Apache Tomcat, 37% chose WebSphere, 22% chose WebLogic and 18% chose JBoss."

    I can understand testing on Tomcat. I always test simple web applications on Tomcat, so Tomcat use at 50% doesn't surprise me, but every place where I've done any strenuous development had some type of EJB implementation; regardless of whether they were phasing out their EJBs and adopting Spring or Hibernate frameworks, there always seemed to be a need for an EJB container. Even when I'm working with a production WebSphere server, there's usually a huge amount of confusion regarding the licensing for a testing server or sandbox environment, so we usually just set up a JBoss implementation to do the basic tests before doing any serious systems integration testing. So when I see 37% of respondents saying they're all about WebSphere, and only 18% saying that they're going to be knee deep in JBoss, I've gotta tell ya, it's surprising.

    And what's more, three of what I consider to be the best application frameworks in existence today, that is, Hibernate, RichFaces and Seam, are all JBoss projects. The simple fact that more and more organizations are adopting these frameworks would surely have a positive impact on the number of people entertaining the use of the JBoss application server?

    I don't know; I really would have thought at least one in five enterprise developers would have put the use of a JBoss application server at the top of their to-do list. I find these survey results interesting, if not a little surprising.


    Replay Solutions 2010 Java Survey Results

    Threaded Messages (79)

  2. Jonas, Orion are there and no GlassFish? Lot of the respondents answered 'other' and I'm wondering how many of them might be using GlassFish. 
  3. Guys, I'm one of the co-founders of Replay Solutions who ran this survey. We ran it for our own research but got such a good response in terms of numbers we wanted to share it with the community. 

    Two things:

    1. We definitely messed up by not including GlassFish. We did have a statistically significant number of 'Other' responses that would have included GlassFish. We also allowed people to add their own info and we'll check how often GlassFish was mentioned.

    2. The numbers for JBoss might have been slightly misinterpreted, again likely our fault. We asked if people were running 'JBoss' (18%) and/or 'JBoss+Tomcat' (15%). So while it's possible that many checked both options, it's also certain the number is higher that 18% for JBoss. 

    You can see the details of the survey here: http://info.replaysolutions.com/l/1772/2010-03-22/15B6T and we've released the raw data to the community as well at the same link.

    Thanks.

  4. Survey Population?[ Go to top ]

    Hi Jonathan.  What can you tell us about the population sample used for this survey?  "IT professionals" does not say much.  Geographic distribution?  Origin?

    For example, did the list come from the ReplaySolutions list of contacts?

    Thanks,
      - eduard/o (a GlassFish guy)
  5. Survey Population?[ Go to top ]

    Hi Eduardo,

    The details of the survey are included in the report at http://info.replaysolutions.com/l/1772/2010-03-22/15B6T.

    Briefly, the demographics surveyed were about 140,000 Java professionals including architects, developers, project leaders and other IT professionals including operational folks. The results were roughly 90% from the USA and Canada, so there is definitely a North American bias in the results.

     
  6. Welcome to self-selection. You're positing a lot of different things there, all different.

    For one thing, the respondents are motivated poorly. The Websphere people are motivated to say so; the jboss people, less so, because historically they've been the red-headed stepchild of the industry. Nobody admits to liking them, and as a result, they resent it and work less with others, which makes fewer people admit to liking them, and as a result, they... you get the idea.

    The PRODUCTS they have aren't the same as JBossAS itself. Hibernate can have been written well, for example, as can Seam, as can RichFaces - Max Katz is a great guy, BTW, and yes, that's a shout-out, holla - but that doesn't mean JBossAS is worth a flip.

    In fact, I'd say it's... really not that good. Compared to Glassfish, it's a hodgepodge of technologies, glued together with elmer's and tape. Geronimo's worse, mind, which is why it wasn't even at 18% -- but the geronimo people will hunt you down and kill you if you point out that the emperor has no clothes.

    The biggest problem, though, is the selection set for the poll. It's never going to be done well, ever. Honestly, you can take results like that and light a fire with them, as far as how accurate/good/useful they are.

    I love captcha - today it's "bedpan also."
  7. Yeah...About Glassfish[ Go to top ]

    Great to see the old editor lurking around in these parts, Joe!

    The lack of any reference to Glassfish seems to be a massive omission. And you're right, it also makes you wonder where Geronimo actually stands in the rankings.
  8. Well said Joe. Most people who feel strongly a particular application server do so for the following reasons:

    1. They know no better
    2. They are the ones who picked it and can't admit it's crap
    3. They could care less and heard about it on threads like this.

    I personally use Jetty and Tomcat, Orion back in the day. My selection of application servers is based upon ease of development, does it provide me what I need and tooling support as well.

    What I want to know is why did the people select the web server they did?

    Capcha: charms released - Interesting..
  9. You clearly is a JBoss Company's fan. That's why you can't understand.
  10. True, I Do Like Them...[ Go to top ]

    Indeed, I am a fan of JBoss and their technologies, such as Hibernate. But as far as application servers go, I'd probably be considered a bigger fan of IBM and WebSphere (I'm the author of "What is WebSphere?"). Still, with JBoss being a free-software, open-source product, which is a concept that is held near and dear to the Java community, I would have thought they'd be gaining ground, and above 20%. 
  11. Simple[ Go to top ]

    Correlate those numbers with those that simply don't feel the need for the entire JEE stack anymore.

    Why don't I, personally, use JBoss: because I don't need to. 

    Why do some people use WebSphere or WebLogic? Because they have to. They have to because of legacy, or because of misguided IT administration policies, or because they actually have a singular need for one or more features only available in those app servers.

    So the simple answer is, you use what you need. And we don't need JBoss.

  12. Also...[ Go to top ]

    The fact that some JBoss projects are popular (Hibernate, yes. Seam, not so much.) has nothing to bear on the popularity of JBoss itself. And I would contest your assertion that nearly everyone uses EJBs. I haven't touched or seen an EJB in about 5 years, and I would be willing to bet that a majority of senior Java developers would report the same.

    EJBs are dead; they really have no purpose anymore. There's a lot of legacy out there, but legacy is legacy: it tends to disappear in time. I got off the EJB bandwagon early, but most have caught up. As a test, do a little survey of how many people use Spring without EJBs, Spring and EJBs or EJBs without Spring; I'm sure you can guess what the results will look like.

    Sun lost the mindshare of the Java community a long time ago; part of the problem is the JCP, and part of the problem is that Sun has been completely focussed in the last 6-8 years on catching up to .NET (when frankly, with few exceptions, there really was nothing to catch up to), rather than coming up with truly novel solutions to business and technical problems. Sun lost, Java won.

  13. Also...[ Go to top ]

    The fact that some JBoss projects are popular (Hibernate, yes. Seam, not so much.) has nothing to bear on the popularity of JBoss itself. And I would contest your assertion that nearly everyone uses EJBs. I haven't touched or seen an EJB in about 5 years, and I would be willing to bet that a majority of senior Java developers would report the same.

    EJBs are dead; they really have no purpose anymore. There's a lot of legacy out there, but legacy is legacy: it tends to disappear in time. I got off the EJB bandwagon early, but most have caught up. As a test, do a little survey of how many people use Spring without EJBs, Spring and EJBs or EJBs without Spring; I'm sure you can guess what the results will look like.

    Sun lost the mindshare of the Java community a long time ago; part of the problem is the JCP, and part of the problem is that Sun has been completely focussed in the last 6-8 years on catching up to .NET (when frankly, with few exceptions, there really was nothing to catch up to), rather than coming up with truly novel solutions to business and technical problems. Sun lost, Java won.


    +1.
    EJBs are dead indeed. Lets not even debate it because one person on this thread still uses it. 
    its like saying EORBA is the best intra - platform integration  language.... duh ! have you heard of web services n stuff ????


  14. Also...[ Go to top ]

    The fact that some JBoss projects are popular (Hibernate, yes. Seam, not so much.) has nothing to bear on the popularity of JBoss itself. And I would contest your assertion that nearly everyone uses EJBs. I haven't touched or seen an EJB in about 5 years, and I would be willing to bet that a majority of senior Java developers would report the same.

    EJBs are dead; they really have no purpose anymore. There's a lot of legacy out there, but legacy is legacy: it tends to disappear in time. I got off the EJB bandwagon early, but most have caught up. As a test, do a little survey of how many people use Spring without EJBs, Spring and EJBs or EJBs without Spring; I'm sure you can guess what the results will look like.

    Sun lost the mindshare of the Java community a long time ago; part of the problem is the JCP, and part of the problem is that Sun has been completely focussed in the last 6-8 years on catching up to .NET (when frankly, with few exceptions, there really was nothing to catch up to), rather than coming up with truly novel solutions to business and technical problems. Sun lost, Java won.


    +1.
    EJBs are dead indeed. Lets not even debate it because one person on this thread still uses it. 
    its like saying EORBA is the best intra - platform integration  language.... duh ! have you heard of web services n stuff ????



    EJBs dead?  Maybe.  I got my quarterly royalty check and statement from O'Reilly today for my EJB 3.0 book.  Sold another 1000+ copies laster quarter for a book printed 4 years ago.

    As for this thread?  Well, as others have stated, I bet a large percentage of the 50% Tomcat deployments are using some piece of JBoss sponsored technology, be it Hibernate, drools, seam, resteasy, infinispan, jbpm, jgroups, or whatever.  We're also active contributors (and provide support) to a multitude of other non-JBoss projects like Tomcat, CXF, mod-jk to name a few.  A lot has happened since 2003! :)

  15. EJBs are dead indeed. Lets not even debate it because one person on this thread still uses it. 
    its like saying EORBA is the best intra - platform integration  language.... duh ! have you heard of web services n stuff ????
    EJBs dead?  Maybe.  I got my quarterly royalty check and statement from O'Reilly today for my EJB 3.0 book.  Sold another 1000+ copies laster quarter for a book printed 4 years ago.

    As for this thread?  Well, as others have stated, I bet a large percentage of the 50% Tomcat deployments are using some piece of JBoss sponsored technology, be it Hibernate, drools, seam, resteasy, infinispan, jbpm, jgroups, or whatever.  We're also active contributors (and provide support) to a multitude of other non-JBoss projects like Tomcat, CXF, mod-jk to name a few.  A lot has happened since 2003! :)

    BTW, Bill, your EJB3 book is *excellent* - it's probably my go-to book for EJB3 overall. Debu's book is better for me for JPA, honestly, and I don't have Reza's book, but I start and end with yours.

    Kudos.

    As for the thread... guys... come on. Look at what you're saying.

    "We, as a self-selected group, SURELY are entirely representative of all Java developers. And we hate EJBs. Therefore, because we know of no EJBs in use, EJBs are useless and dead. Viva web services - because nothing says quality like transaction semantics that have no guaranteed effects!"

    See, I'd say web services are dead, because only fools rely on them. EDI is far better, but it's not "cooler." And *I*, you see, see myself for what *I* am - a self-selected group of one. 

    I don't have the ego to say "I like X, so everyone likes X." Bill, good on you - and good luck in the future. But the rest of you? Meh. Even if you're right, you come across as ... well... I shouldn't say.  ("Arrogant weasels?" "Shore ons?" "Viddy dots?" Ah, if only the Bileblog were here.)

    Wonderful captcha: "skatches some"! I don't know what it means when I get such joy out of the captchas. :)
  16. Also...[ Go to top ]

    Bill,

    Well said and good to see you around. We have similar results for EJB 3 in Action, not to mention the large percentage of my own former clients consciously choosing Java EE 5/Java EE 6/CDI/EJB 3+/Seam over Spring for good technically sound reasons. I think this type of "X is dead" statement is a throwback to the past. The reality is that the Java world is just to large, dynamic, competitive and diverse to make these types of assertions. I think the same is true of the app server market share data. It is definitely interesting as a snapshot, but hardly something that is likely to remain static for long.

    The assertions about the JCP are obviously silly. Even the biggest anti-Java EE fanatic can see that a large part of Spring 3 is dedicated to Java EE 6 API support and that almost all Java developers pay close attention to the work of the JCP.

    Cheers,
    Reza
    ----------------------------------
    Author, EJB 3 in Action
    Expert Group Member, Java EE 6 and EJB 3.1
    Resin EJB 3.1 Lite Container Lead
  17. Also...[ Go to top ]

    In the adult world, when communicating from disparate systems in a HA/Fault Tolerant environment, you use MDB's.
  18. My reaction to somebody who uses JBoss is "Really?  Why not Tomcat?".
  19. My reaction to somebody who uses JBoss is "Really?  Why not Tomcat?".


    +1.
    why use JBoss if get everything out of Tomcat( ofcourse for EJB n stuff there is need of Jboss or weblogic or whatever else).
    But i would choose tomcat over jboss because of simplicity. Jobss MAY be a good software but their documentation sucks big time, they change too many things too often and ignore some backward compatibility issues.

    I was recently working on DROOLS by JBoss. They have changed so many things in that product including name was changed 3 times. It is so difficult to follow up.
    Ofcourse i can pay them for their services and may be they can help. But then JBOSS should nto tout themselves as open source company because their community versions are crap , not at all documented well.
  20. bad documentation isn't unique[ Go to top ]

    My reaction to somebody who uses JBoss is "Really?  Why not Tomcat?".


    +1.
    why use JBoss if get everything out of Tomcat( ofcourse for EJB n stuff there is need of Jboss or weblogic or whatever else).
    But i would choose tomcat over jboss because of simplicity. Jobss MAY be a good software but their documentation sucks big time, they change too many things too often and ignore some backward compatibility issues.

    I was recently working on DROOLS by JBoss. They have changed so many things in that product including name was changed 3 times. It is so difficult to follow up.
    Ofcourse i can pay them for their services and may be they can help. But then JBOSS should nto tout themselves as open source company because their community versions are crap , not at all documented well.

    Honestly, having contributed to various open source projects, bad/poor/lacking documentation isn't unique to open source projects. I've seen plenty of commercial products with lousy documentation. I'll go one step further and say bad docs are the norm and good docs are the exception. my bias 2 bits.
  21. My reaction to somebody who uses JBoss is "Really?  Why not Tomcat?".

    Apples need to be compared with apples, right?
    Tomcat is a JSP/servlet container (web server). JBoss AS is an application server that includes both EJB AND jsp/servlet container.
    Moreover, the JBoss servlet container is based on Tomcat. Surprise, Surprise ;)

    While the one might not like JBoss for the sake of just not liking, the deploying of WAR to JBoss AS is not any different to Tomcat - just put your archive to deployment directory.
    That's why some statements in this thread regarding Tomcat vs JBoss AS made me laughing...

    Still don't believe me? Visit http://www.jboss.org/jbossweb
  22. My reaction to somebody who uses JBoss is "Really?  Why not Tomcat?".

    Because Tomcat doesn't come with JavaServer Faces, Enterprise JavaBeans, Java Persistence API, Java Transaction API and Java Message Service?
  23. Uh.  Yeah that is the point. You can get almost of what you listed except JSF. Thank God!!!!
  24. UCL[ Go to top ]

    Back in 2003-2005, I used JBoss AS 3.2.x heavily.  The Unified Classloader left a bitter taste in my mouth.  I've avoided it since.
  25. UCL[ Go to top ]


    Tomcat is an obvious choice is not a  surprise.
    (its fast, stable and very well documented)

    EJBs(or app servers) are not useful - as entity bean can be replaced by JPA and session beans by webservices.

    However sometimes you may be forced to use appserver  - as you may buy some products like blaze advisor which would need app server(read EJBs) to deploy web services. (JMS is another reason for
    staying with app servers)



    Thanks,
    Zahid
    http://wwww.jroller.com/zahid

  26. EJBs(or app servers) are not useful - as entity bean can be replaced by JPA and session beans by webservices.

    Webservices are not really useful - SOAP is too complicated, too slow - a soap webservice can be replaced with JAX-RS ;)

    Seriously, every approach and technology has a niche, depends on business requirements, and if tech docs read before applying - it works just fine. Saying that app servers (read SLSB, MDB) are not useful is just like saying that java is dead, earth is flat, etc. ;)
  27. No SOAP.. More REST[ Go to top ]

    This is the route we are heading on our current project. Highly recommended!
  28. UCL[ Go to top ]

    Zahid,

    The truth is that EJB is only one reason to use an application server. Most application servers come integrated with a lot more that a plain Servlet engine simply does not - a JTA compatible transaction manager, database/resource pooling, clustering, load-balancing, management facilities, etc just to name a few. This is one of the reasons why Caucho customers continue to choose Resin over Tomcat and Jetty. I would suggest that you give the "Resin and Servlet Containers" section a careful read in this blog post: http://blog.caucho.com/?p=384.

    Cheers,
    Reza
  29. UCL[ Go to top ]

    EJBs(or app servers) are not useful - as entity bean can be replaced by JPA and session beans by webservices.

    2002 just called, they need you back there.

    FYI, CMP Entity beans have long ago (since 2006) been replaced by JPA entities in EJB. Better yet, EJB has first class support for JPA and I really wouldn't want to use JPA without EJB.
  30. Websphere and IBM JVM %[ Go to top ]

    Amusing:
    37% for Websphere and only 21% IBM JVM? There is a big problem here, Websphere can't run on a non IBM JVM... By the way Websphere doesn't run but drag ;-)
  31. The survey should've more depth in covering the reasons for selecting a particular application server. The debate engaged should have substance of why a certain application server would be preferred. The Jboss application server which was used in my current project has yielded the desired results with Tomcat as the Web server. The distributed architecture with clustering requirement was done successfully. I do understand one's inclination for selecting a application server is usually based on their past experiences. This debate can be positively channeled into evaluating the application servers where they are best suited for their purpose which can help the tech community in making decisions.

    Regards,
    Vishwanath

  32. This debate can be positively channeled into evaluating the application servers where they are best suited for their purpose which can help the tech community in making decisions.
    Bravo for saying this and I really do hope somebody knowledgeable without an axe to grind would come along and do exactly such as analysis (the same for a Java EE 6, Seam 3, Spring 3 analysis). It's a shame people like that are becoming rarer and rarer. Personally, I am encouraged that the new TSS editor has such a diverse development background...

    Cheers,
    Reza
  33. If you take a quick look at the raw data in a spreadsheet - you'll see the questioning, analysis and presentation of the results was poor. The JBoss number is the "JBoss" column + the "JB,TC" column, similarly for Tomcat. The numbers then come out as you would expect : Tomcat = 32%, JBoss = 22%, Websphere = 19%, Weblogic = 11%, Other = 9%.

    Omitting Glassfish was another mistake - it's a significant piece of the other - probably 5-6%.

    This is consistent with other surveys I've run personally and other data I've seen. The big surprise to me is the extent to which Weblogic has fallen behind over the years.

    Rich Sharples
    JBoss by Red Hat 
  34. For what it's worth, I've elaborated a little more on my point about the poor analysis and presentation :


    Rich Sharples
    JBoss by Red Hat
  35. I really thought WebLogic was going to just kill WebSphere. I mean, when we went in and sold WebSphere, it was always to customers running Oracle. But for Oracle to be able to go in and sell their middleware product, WebLogic, alongside their Oracle database, well, I just figured that would be too tough of a combination to beat. But it doesn't seem like my prediction has come to fruition at all. WebLogic still can't seem to get into the markets in which WebSphere's Application Server dominates.

  36. I really thought WebLogic was going to just kill WebSphere. I mean, when we went in and sold WebSphere, it was always to customers running Oracle. But for Oracle to be able to go in and sell their middleware product, WebLogic, alongside their Oracle database, well, I just figured that would be too tough of a combination to beat. But it doesn't seem like my prediction has come to fruition at all. WebLogic still can't seem to get into the markets in which WebSphere's Application Server dominates.

    I don't think any product can "kill" WebLogic or WebSphere .. they are just too deeply entrenched and each has various sticky bits which are hard to replace. On the other hand, I have personally seen WebLogic displace WebSphere in a number of accounts since the acquisition by Oracle. I think WebLogic is going to do just fine .. ;-)

    Peace,

    Cameron Purdy | Oracle Coherence
    http://coherence.oracle.com/
  37. I really thought WebLogic was going to just kill WebSphere. I mean, when we went in and sold WebSphere, it was always to customers running Oracle. But for Oracle to be able to go in and sell their middleware product, WebLogic, alongside their Oracle database, well, I just figured that would be too tough of a combination to beat. 
    I wouldn't give up on Oracle just yet...

    BEA always had excellent technology, but never knew how to make a profit from it.  I first started using Weblogic in 1999, and I had really hoped that their technology would not be lost.  I wasn't overjoyed by the Oracle acquisition, but I was relieved.

    My guess is that Weblogic as we know it will cease to exist in the next 3 to 5 years but the underlying technology will be rolled into the Oracle Fusion stack.  I've been working with Fusion, and although it is very expensive, is also incredibly powerful.

    Because of the commoditization <!--<a href="http://www.theserverside.com/">if gte mso 10</a>><br> <style><br> /* Style Definitions */<br> table.MsoNormalTable<br> {mso-style-name:"Table Normal";<br> mso-tstyle-rowband-size:0;<br> mso-tstyle-colband-size:0;<br> mso-style-noshow:yes;<br> mso-style-priority:99;<br> mso-style-qformat:yes;<br> mso-style-parent:"";<br> mso-padding-alt:0in 5.4pt 0in 5.4pt;<br> mso-para-margin-top:0in;<br> mso-para-margin-right:0in;<br> mso-para-margin-bottom:10.0pt;<br> mso-para-margin-left:0in;<br> line-height:115%;<br> mso-pagination:widow-orphan;<br> font-size:11.0pt;<br> font-family:"Calibri","sans-serif";<br> mso-ascii-font-family:Calibri;<br> mso-ascii-theme-font:minor-latin;<br> mso-fareast-font-family:"Times New Roman";<br> mso-fareast-theme-font:minor-fareast;<br> mso-hansi-font-family:Calibri;<br> mso-hansi-theme-font:minor-latin;}<br> </style><br> <!<a href="http://www.theserverside.com/">endif</a>--><!--<a href="http://www.theserverside.com/">if gte mso 9</a>><xml><br> <o:shapedefaults v:ext="edit" spidmax="1026"/><br> </xml><!<a href="http://www.theserverside.com/">endif</a>--><!--<a href="http://www.theserverside.com/">if gte mso 9</a>><xml><br> <o:shapelayout v:ext="edit"><br> <o:idmap v:ext="edit" data="1"/><br> </o:shapelayout></xml><!<a href="http://www.theserverside.com/">endif</a>-->of basic middleware, it only makes sense that the Weblogic technology get folded into a stack that reaches up into the application layer and down into the RDBMS.  Also, Oracle is eating its own dog food - rewriting E-Biz Suite and a number of other apps on the Weblogic-based Fusion stack.

    If you start seeing companies adopting Oracle Fusion, then you are seeing wins by the technology we knew as Weblogic. Edited by: Cameron McKenzie on Apr 9, 2010 5:28 PM
  38. Glassfish is killing it ..[ Go to top ]

    Omitting Glassfish was another mistake - it's a significant piece of the other - probably 5-6%.

    This is consistent with other surveys I've run personally and other data I've seen. The big surprise to me is the extent to which Weblogic has fallen behind over the years.

    Rich Sharples
    JBoss by Red Hat

    The Glassfish numbers are incredible. Even before Oracle bought Sun, Glassfish had more momentum than any other app server in the market.

    As for Weblogic, it is actually growing, but it's so established and mature (not to mention that it's an expensive enterprise-class product) so the growth is understandably at a slow rate.

    Peace,

    Cameron Purdy | Oracle Coherence
    http://coherence.oracle.com/
  39. When I speak to users, I am hearing that they are moving to Tomcat, away from legacy Java EE application servers for variety of reasons such as cost reduction, reduce runtime complexity, remove friction between development and production deployments and also for ease of support.  Most of them are realizing that they are either not using the full Java EE stack and its an easy move to Apache Tomcat.

    What is interesting is that several of these migration projects are driven by people in IT operations, so, its not just developers telling production guys that they should switch to Tomcat. Folks managing application servers are increasingly getting frustrated with the complexity of Java EE application servers. Moreover, products like Tcat Server and other products are helping make this migration easier. 

    Best Regards,
    Sateesh
    Disclaimer: I work on Tcat Server.
  40. As far as I've seen, using Tomcat does nothing to reduce complexity in either development or administration (in fact, for the reasons outlined in the Resin Java EE 6 Web Profile road map quite the opposite is likely to be true for most shops). Now, heavyweight footprint, agility and cost are good reasons to switch away from full-scale, commercial offerings (the GlassFish data would have shown that).

    Then again, that is what the Java EE 6 Web Profile is tailored to address without devolving to a "kit car" development mind-set (again, discussed in our road map). Besides Resin, GlassFish supports the Java EE 6 Web Profile - I believe JBoss and Geronimo have plans to support the Web Profile too. Hopefully, the WebLogic and WebSphere guys will see the light too, but I kind of doubt it given their target market.

    I've personally encountered no such Java EE application server -> Tomcat migration in a pretty wide range of companies over a long period of time. What I have seen is people who invest in Spring whole-hog going the Tomcat route to begin with. There is a similar pattern of a lot of Java EE 5/6 adopters going the GlassFish route (not good news for us/Geronimo/JBoss but not really anything to fret too much over either).

    As to the "WebSphere vs. WebLogic" point, I think the key fact there is that the WebLogic brand has eroded significantly while the "IBM shops" continue to have brand loyalty to IBM. Sadly, a few of these decisions are purely technologically driven - primarily because in most organizations these decisions are being made by the wrong set of people to begin with that are quite out-of-touch from day-to-day development/administration/troubleshooting.

    Cheers,
    Reza
  41. I completely disagree how you rated tomcat as a sandbox web server.  Here's my question.

    What makes other web server more secure than Tomcat? What do you gain by using JEE server vs using Spring Framework enterprise services?  I assure you, I have deployed very big and complex projects on tomcat that perform well beyond than JEE server.  As of today, I still don't see any reason to use JEE server that tomcat can't do. 
  42. Hey Kevin. The goal wasn't to paint Tomcat or Jboss as a sandbox only environment. My point is that I usually use both as sandbox test servers, even when the directors of the company have chosen WebSphere or WebLogic as the production box. Indeed, I've deployed many enterprise ready applications that leverage Spring and Hibernate on Tomcat, without any EJB container whatsoever.
  43. My point is that I usually use both as sandbox test servers, even when the directors of the company have chosen WebSphere or WebLogic as the production box.
    Your point was totally clear - I too tend to see JBoss and/or Tomcat used for testing, development in shops that use WebSphere/WebLogic in production (and understandably so). In fact, I'd say accounting for that you would see a fairly significant drop in both JBoss and Tomcat numbers. That's another area the survey could improve - differentiating between production and non-production use.

    Cheers,
    Reza
  44. Kevin,

    Take a look at the blog entry I posted earlier for the answer to this question if you have sincere interest and don't think you already know everything (as most Spring zealots tend to think they do), as well as my only slightly outdated Java EE 6/Spring 3 comparison: http://www.redhat.com/f/pdf/jbw/rrahman_320_spring_framework.pdf. I'd certainly like to know what you have to say after that.

    Java EE application servers offer usability, robustness, performance, manageability, standardization and ease-of-development, ease-of-configuration. And I too have developed both Spring and Java EE application servers just as Cameron has (and have come across myriad performance and configuration complexity issues with Spring/Tomcat starting from a lack of basic connection pooling to hard-to-debug thread-safety issues that emerge only at runtime). From the sounds of it is highly doubtful you have any real experience developing with Seam, Java EE 5 or Java EE 6. If you did, I contend that the answer would have been obvious to you just as it is for numerous other developers.

    Cheers,
    Reza
  45. Reza -

    Great answer.  EJB 2 was a mistake, EJB 3.0 (and 3.1 in particular) along with CDI have really improved things.  Spring clearly filled a need when the standards were lacking, but the landscape has really changed and those who say EJB is dead haven't used EJB 3/3.1.  If one needs standard support for transactions, scalability, pooling, and prefer annotations to XML configuration, EJB 3 and Java EE deserve a look.
  46. Greg,

    Thanks for the kind words. It's just plain annoying to continue to see this type of obviously one-sided FUD these days considering that Java EE and Seam really have picked up a lot of traction (admittedly to my own surprise - I would not have believed it a few years ago).

    Cheers,
    Reza
  47. Genuitec from MyEclipse fame had a poll a while back and the results were a little different. See http://www.myeclipseide.com/Poll-8.html

    What's Your Favorite App. Server

    Tomcat   43 %43 %43 % 43.20 % (375)
    JBoss 25 %25 %25 % 25.46 % (221)
    WebLogic 11 %11 %11 % 11.87 % (103)GlassFish 7 %7 %7 % 7.03 % (61)Geronimo1 %1 %1 % 1.04 % (9)Jetty1 %1 %1 % 1.04 % (9)JOnAS0 %0 %0 % 0.69 % (6)JRun0 %0 %0 % 0.81 % (7)Oracle1 %1 %1 % 1.84 % (16)Resin1 %1 %1 % 1.73 % (15)WebSphere5 %5 %5 % 5.30 % (46)

    Hmmm, Preview on this site does not show what you *really* get after a post :(

    Let's try again:

    Tomcat 43.20 % (375)

    JBoss 25.46 % (221)

    WebLogic 11.87 % (103)

    GlassFish 7.03 % (61)

    WebSphere 5.30 % (46)

    Oracle 1.84 % (16)

    Resin 1.73 % (15)

    Geronimo 1.04 % (9)

    Jetty 1.04 % (9)

    JRun 0.81 % (7)

    JOnAS 0.69 % (6)


  48. Favorite vs. Using[ Go to top ]

    It's interesting to see what the response is when someone says 'what are you being forced to use at work' as opposed to 'what is your favorite.'

    WebSphere at 5%? Considering how bit its user base is, that's pretty dismal. :(

    Yeah...the preview...new system, and they're working on it.
  49. Favorite vs. Using[ Go to top ]

    It's interesting to see what the response is when someone says 'what are you being forced to use at work' as opposed to 'what is your favorite.'

    Indeed, this would be rather interesting. Have the same interview ask for:

     * What AS do you use for development and/or testing?
     * What AS do you use in production?
     * What is your favorite AS?

    I would hope that most people would be able to give the same answer for all three questions, but maybe in practice this wouldn't always be the case.

  50. pressures[ Go to top ]

    There are some reasons why the unthought technology was chosen in the history: Finantial/business authority (better power) directed the choice, Some from firms are friends or any main head reads whitepapers wthout consulting it. The WebSphere is e.g. mandatory in banks.
  51. Hi All!

    (I didn't manage to read all comments so somebody else may have written the same as me)

    First of all, choosing an app server today is not an easy task. The question about what application server one is using is just not about a brand. Such a question must be put into an extra context about what you are looking for when deciding what application server to use. So the question about what application server one is using would probably get a better answer with a complementary question asking why that choice is done.

    Never underestimate the importance of support. If you're on a bigger company you want support. No matter how good or bad the support is, you still want to have a support agreement. Sometimes you buy a more expensive product to hand over a bit of responsibility to a product company.

    You can get support from most vendors but I think the open sourced brands disqualify them selves here - just because their main products are open source. They are pushing the open sourced community driven version of the product. Many people don't think they are focusing on enterprise products. Most often when I tell people that you can sign a support agreement for JBoss or Glassfish you get an "- Aha interesting", in response.

    Ok, now telling from my own experience. JBoss has a long way to go when it comes to be more enterprise. It's not uncommon that JBoss does drastic changes in an minor releases. As an example, they changed the whole web service implementation between version 4.0.3 and 4.0.4 and no old web service based apps did work after an upgrade. I can understand that JBoss did the upgrade of that implementation to becom more standrd, but not when just increasing the least significant version number.

    I can't just blame JBoss here. I'm a fan of JBoss. I've been working a lot with the JBoss AS product and as a person who likes using new exciting technologies JBoss is a platform for me, for my own enterprise development. For me JBoss is pushing the Java EE forward by creating new exciting technologies that gives me a lot of good software to use.

    So choosing between open source and commercial products is mostly about what you are going to do. The above is a good example about what I mean. The open source community gives us the new software by pushing new technologies beyond the borders all the time. The "more" enterprise focused vendors gives us robust application servers not containing the bleeding edge technologies.

    What I want to say is the "more" enterprise thinking organizations do take better care about not messing an old installation on upgrade by having thoughts about backward compability. But such an enterprise thinking costs in support of fewer "hot" technologies.

    So if youâ??re going for bleeding edge technology, choose an open source product (then you probably know what you are doing and you're capable of manage all types of diferent configurations). If you want a robust system, go for a "more" enterprise thinking solution and buy support, but do not expect the latest stuff here.

    Oskar

     

  52. With all due respect Oskar you are really not getting it. Open Source projects used in production software are highly stable. In fact I bet if you could get test coverage numbers for those Closed Source projects vs those from Open Source you would likely go it to cold chills. You are making blanket statements and strawmen arguments that don't hold water in comparison with the real world.  I have worked on lots of projects using Closed and Open source and the easiest to use and best supported products have always been the Open Source ones. Sure there are some that aren't that way but, they typically aren't as mature.

    I think the argument you are making is really about control and a perception of safety. You want to feel like you have a fall back position if something goes wrong and a person or company to point blame at if it does.  You also want to have all the developers corralled into a certain mindset and limit creativity.  This is only hurting your projects not helping them.

    I would guess the rare times you have taken advantage of your support contracts has turned out to be really user error. Now with that in mind what are you costing your company on support contracts that could have been resolved with a post to a user forum or a Google search.

    If I have misunderstood your position or been to harsh my apologies but, I am seeing a position that is all to prevalent and personally I am tired of encountering it.
  53. I would guess the rare times you have taken advantage of your support contracts has turned out to be really user error. Now with that in mind what are you costing your company on support contracts that could have been resolved with a post to a user forum or a Google search.
    Jason, there are many cases when you need support because there is a bug that is not going to get fixed otherwise ( i.e. https://jira.jboss.org/jira/browse/JBWEB-101 two years to be fixed, was fixed when I reported the issue as a jboss customer ) by having paid support you have the chance to push a little bit harder to get a developer to fix the issue.
  54. I meant 1 year, not two.

    btw, I am a happy jboss customer I didn't mean to bash jboss
  55. Hello Jason!

    A bit of misunderstanding here. I wasn't clear enough in what I meant. I didn't mean open source products are more unstable than other more commercial ones. What I meant to say was that there is a business case here in "not under estimating the importance of support agreements". This is about psychology and politics - not technology.

    I totally agree with you that open source products are stable, and maybe more often, better than commercial versions. And of course you can get fast help from the community. No doubt about that. Still the fact is that most business people doesn't now about putting high values on an open forum. It's like paying is safe and you hand over some responsibility to the product (again psychology and politics).

    Back to technology focus again. The fact is that when you are making newer technologies available in your software you are also adding software that are not tested in long run production environments. This is a risk. Even if if it's a small risk, it is still a risk. But the value this extra functionality adds shall always be seen in contrast to the risks.

    The commercial brands, as I said in my previous comment, are supporting older technologies that are said to be more stable. I'm not saying these technologies more stable in practical use, they are just told to be more stable. Again it's about psychology when it comes to business.

    As You have, I've also worked with a lot of both closed and open sourced products. And I prefer using Apache Tomcat/Jetty (most often I don't need more functionality than that), JBoss and Glassfish in front of Oracle's and IBM's software. Just because I put a higher value on new technologies and fast support from an open forum than from a closed support department.

    Cheers,
    Oskar

  56. This kind of article is a perfect example of how some architects and developers are out of touch.  They think they are mainstream and think the EJB route is mainstream when the community is going lighter and more pragmatic. Most project only need DI, DB connection pooling, and remoting capabilities that are configurable.  Spring and Tomcat (or servlet container of your choice) get you there.  The full EJB stack should not be the default choice. And you white hat architects that think JMS is the end all be all. Really? WAKE UP!!!!
  57. Quite frankly, I find this whole "default choice" idea pretty stupid - it echos mindless "corporate standards" that don't actually do much informed analysis. People should choose the technology stack that is right for their project and team instead of following a "default choice" as if it were the latest "must have" fashion rage...

    Cheers,
    Reza
  58. I agree Reza! The pragmatic/agile approach is to pick the toolset that best fits the project. I say start off with out the container and see where it takes you.  Maybe you find you don't need maybe you will.  But starting off with a EJB container is a mistake.
  59. Waking up[ Go to top ]

    This kind of article is a perfect example of how some architects and developers are out of touch.  They think they are mainstream and think the EJB route is mainstream when the community is going lighter and more pragmatic. 

    This kind of reply is a perfect example of how some TSS readers and Spring zealots are out of touch. EJB 3.1 has a very lightweight and enormously pragmatic programming model.

    WAKE UP JASON! It's not 2002 anymore...

    p.s.

    Your post is laughable stereotypical: "EJB is completely outdated/dead/not relevant. Community moves to free/open-source/lightweight solution. Use Tomcat and Spring! It gives you everything/works the best/is unbeatable"

    Do you guys like use a template generator or so for these comments? Am I actually replying to a human or is this some bot generated content that is triggered by the keyword EJB?
  60. I am a pragmatic technologist.  I have developed EJB 3 apps and I still go back to Spring only because of the container requirement. But only as a start. If things aren't going to scale then deploying into the container may make sense.

    Use the container when you are looking for large scale high volume (millions of transactions per mintute/second) apps.

    I didn't infer that EJB is dead you inferred that.  I am saying a pragmatic view is important and usually you will find that a container isn't necessary.
  61. Use the container when you are looking for large scale high volume
    (millions of transactions per mintute/second) apps.
    To this I'd add the Java EE stack is the obvious choice for people that don't particularly care for configuring frivolous things (usually in verbose, unreadable XML) like a transaction manager, security provider, annotation processor, database pooling, robust thread-safe messaging, persistence-provider, context management, web framework, AOP processor and so on and so forth that the runtime should simply do for you to begin with since you are developing a server-side app, not a Hello World console application. I'd also add people that are not overly excited about using a non-standard API for weak reasons in support of a wannabe monopolist that declares themselves a de-facto standard in a highly competitive industry full of bright, talented people...

    Cheers,
    Reza
  62. Now you have lost me, I thought we had a common point to agree on.  Please don't revert to the same uninformed accusations you say Spring "fanatics" make.

    I have a Spring config file in my current app that is 51 lines long and that includes the namespace descriptors. It has everything I will need for a while. At a glance I can find what I need to know about my configuration.  Where a container set up would require looking through several xml files or poking through usability challenged web pages that requires the container to be up and running.

    I have seen the obscene Spring files you mention but, that was a pre-Spring 2.5 app and it wasn't pretty.  At that time containers "were"/are still a pain to test and develop on.

    As for "non-standard API" at this point we are talking about a annotation difference in most cases.  Not much of an effort to switch between the two if I have to, or use both if I want to.

    Personally I don't put much weight into "standard APIs".  The point of a standard API is to abstract layers and make them switchable.  Considering the life span of most applications and the likely hood an organization would make that kind of a switch is unlikely and very rare at best.

    Not to mention by the time they would make that consideration the next version(s) of the "standard API" have been already been released and your facing some breaking changes anyway. Don't get me wrong standardization is important.  I just think it is credited with more that it ever really achieves.
  63. Sorry, but you and I are not on the same page at all. And the "uninformed accusation" part is especially funny considering I've used Spring since 2.0 and was one of the first people I know working on Spring 3 code.

    I think having to do any system level configuration for the stuff I mentioned is just plain silly. Take a look at the PPT I posted earlier to see what I mean. On Spring projects, I spend 60% of my time fixing botched Spring config that's neither easy nor very natural and often requires reading through reams of Spring documentation, not to mention being totally redundant compared to a Java EE application. Just try explaining some Spring configuration to a newbie and see how easily it goes over. In comparison, I've seen people come up to speed on Java EE 5/6 code a lot easier because such configuration just doesn't exist there and almost everything is just annotated Java code (maybe with the exception of persistence.xml). In fact, I know people whose sole consulting career is based on arcane Spring configuration that they carry from project to project (curiously these are the same people that really "love" Spring - gee, wonder why?).

    It's equally silly to bind yourself to any non-standard API without a very good reason. I've been on plenty of technology projects whose sole purpose was to switch vendors to know better about staying as technology and vendor agnostic as possible. It's tough enough to switch even for projects that do use standard APIs, it's near impossible for a moderate sized application with vendor specific annotations peppered in all over the place starting from the basic component definition to injection and transaction management.

    That being said, there's plenty of developers with control issues/way too much time on their hands that feel like they have to configure everything about their application from scratch (like the idiots that build their own Linux distribution instead of getting a pre-configured distribution from a vendor) and there certainly are people who love proprietary APIs from Microsoft. If that stuff's OK, I guess Spring isn't "so bad" after all :-).

    Cheers,
    Reza
  64. I finally got through your slides and I do see the point you make about how EJB is more configurable through annotations than Spring. That is certainly more desirable. I have not seen or had the issues you have mentioned with Spring configuration. 60% of your time wow sounds painful maybe someone should have gotten fired.

    Testability is more important to me in the long run. I have not seen yet any good solution for integration testing with EJB implementations.

    The Microsoft comparison is an interesting one. This could be done in any context. You could do it with Sun/Oracle. You could even make the statement that their style is becoming more like Microsoft's style especially when you compare the full product stacks of each and how they market themselves. Personally I think this line of thought is just as flawed as the original.  They are all different solutions to, to pit one against the other in this manner doesn't win the argument.

  65. Jason,

    If you are really concerned about testability, take a look at embedded containers that were standardized as part of Java EE 6 as well as projects like JBoss Arquillian (http://community.jboss.org/docs/DOC-14376?uniqueTitle=false) that do great integration with JUnit and TestNG as well as allowing for in-container as well as out-of-container testing (not to mention our Resin specific JUnit integration posted earlier as part of our road-map). It's funny you claim you used EJB 3.0 yet know nothing about testing solutions like OpenEJB (http://openejb.apache.org/) that has been around since Java EE 5.

    If you really don't see how using a vendor-specific product like Spring when a standard API like Java EE will do just fine gets you closer to a proprietary model, I really don't know what to tell you!

    Perhaps you haven't come across the myriad configuration headaches that Spring causes because you haven't done very large projects with Spring. Try to do a little bit of web services, remoting and messaging with Spring and see what happens with your precious Spring XML configuration as compared to a Java EE 5 based system (I've shown that in my Spring/Java EE 6 comparison slides)...

    Cheers,
    Reza
  66. Dude I have given you props and agreed with you in some cases but, you still keep coming at me. :)

    The EJB 3.0 project I was on was early enough that the micro containers weren't around yet, or were pretty immature, JBoss 5.0 was still vaporware. Sounds like OpenEJB would probably similarly placed. 

    If the micro containers aren't inverted enough I would still be concerned about using them.  I will take a look though.

    I have been on large scale Spring projects with a large number of Spring config files. Yeah I agree it is a pain and I have an appreciation for annotation based configuration to alleviate that. I was even disappointed when I first found out that Spring hadn't taken it far enough to include remote services in 2.5. 

    I have avoided web services because most apps I have worked didn't need them. Spring Remoting (RMI/HTTP-Invoker) was good enough for us.  The times we did external facing the use of Web Services was minimal. I have avoided Web Services intentionally until something better was to come along. Spring Remoting is kickin' because it is configurable to do all those things you mention.
  67. Jason,

    I have nothing against you personally and do appreciate the fact that unlike some other Spring "enthusiasts", you are actually professional enough to admit when you are not entirely correct.

    Do us all a big favor though and please carefully check your facts before posting negative remarks on anything. It's OK to make one or two mistakes every now and then (we all do), it's another to keep doing it on the same thread repeatedly like you have here. I've been using OpenEJB for testing since late 2006 - that's well before Spring 2.5 finally got around to adopting annotations. I won't bother asking you when you actually used EJB 3.0 or what your specific complaints for Seam are (BTW, feel free to post your comments to the Weld/Seam 3 forums since it is currently under very active development). It's not 2005 anymore and do expect opposition to anything that looks like SpringSource FUD that we've all heard before (better yet, do yourself a big favor and don't immediately believe everything SpringSource says before checking the facts - after all they do have a vested interest in distorting things in their favor like every vendor).

    All that being said, if you genuinely prefer Spring style development after having taken a good look at how the alternative looks like, there is nothing really wrong with that (as I've outlined in my slides there are some solid technical points to consider). There are also some good non-technical reasons to be adopting Spring - such as a larger deployment base (at least for now), the ability to use the latest API if you don't have control over your application server upgrade schedule, maturity compared to Java EE 5/Java EE 6/Seam, deploying applications to environments you don't have control over, etc. If you are going to make a case for Spring, I would say these are much stronger points compared to the nonsense that comes out of SpringSource that's really very outdated and stale.

    Cheers,
    Reza
  68. This discussion has been very good for me. We, the project team, are going into these kinds of discussions with another project group that have created a colossal EJB/JBoss app. They are having huge issues and we aren't. Considering the level of transactions they will be handling the choice hasn't made sense.  They are building a SOA style app for integrated other Java applications and it will only see hundreds of transactions per minute for the lifetime of the application.

    The key problem there is who is implementing it and the mind share of the team more than the technology itself.


  69. Jason,

    Glad to hear this was helpful. I agree technology choice is a highly team dependent thing more than anything else. I've seen people develop great VB 6 applications although VB 6 isn't something I would personally use ever (just as I try to avoid Spring when possible).

    In any case, if it helps, feel free to send me questions with regards to Java EE 5/Java EE 6/CDI/Seam/EJB 3/JBoss (thanks to Google, I'm pretty easy to find). If you happen to go the Seam route, I am happy to get you in contact with the Seam developers too. I know plenty of successful Java EE projects, with or without Seam so I am very disinclined to believe technology has much to do with the issues you mention you are having. Here is a list of people (self-selected) using Seam that JBoss put together a while ago: http://seamframework.org/Documentation/SeamInProduction. We are thinking of putting together some similar case studies for Resin customers using our Java EE stack.

    And no worries - any answers are free of charge just as they are here - although a Cognac, Gin/Tonic or Scotch is highly appreciated if we happen to cross paths at a conference some time :-).

    Cheers,
    Reza
  70. I have developed EJB 3 apps and I still go back to Spring only because of the container requirement. [...]

    I am saying a pragmatic view is important and usually you will find that a container isn't necessary.

    What exactly are you trying to tell me Jason? You don't use EJB because it is/requires something called a container, thus you use Spring which basically also is a container?

    Something doesn't it add up here. It strongly reminds me of yet another Spring zealot circular argument: EJB is bad because it is a container. A container is bad because EJB is a container. It just doesn't make sense. None of that makes sense. If you ever watched south park, I'd say it's pretty close to the infamous Chewbacca argument.

    I do know where you coming from, and that's early 2003, when Rod tried to put a smudge on the words "application server" and "container". Spring zealots of that time still refer to anything related to that as inherently bad. It doesn't require any further explanation -why- a container would supposedly be bad, since Rod has simply said so, ain't I right?

    Of course the big irony is that Spring does now have an application server too, which is actually the preferred way for a Spring stack. And of course, Spring beans also live inside a container.

    I respect the sentiment that sometimes you don't need all the power Java EE and/or EJB offers and that a plain Tomcat will work, but it's pure nonsense to say you are pragmatic and don't need Java EE, yet you supposedly do need Spring, which offers a very similar feature set. I simply don't think that this is right. Spring is not any inherently more pragmatic than Java EE. They are both powerful and capable stacks, roughly in the same league.
  71. I respect the sentiment that sometimes...a plain Tomcat will work
    Curiously, this is exactly the case that some people (you can guess who) tried to make in the Java EE 6 EG with respect to the Web Profile. Personally I think using plain Tomcat without Spring or another embedded runtime container (like Seam, OpenEJB, etc) is totally without any merit. The code that would ensue would be grossly verbose and unmaintainable - reminiscent of spaghetti code from the early nineties.

    In reality, choosing just a Servlet engine basically binds you to Spring and forces a configuration burden that simply does not exist with a full Java EE 6 stack or a Java EE 6 Web Profile stack. I guess at least these guys have the option of using Seam or OpenEJB that's a lot easier to configure compared to Spring's "configure everything" philosophy.

    Cheers,
    Reza
  72. I respect the sentiment that sometimes...a plain Tomcat will work
    Curiously, this is exactly the case that some people (you can guess who) tried to make in the Java EE 6 EG with respect to the Web Profile. Personally I think using plain Tomcat without Spring or another embedded runtime container (like Seam, OpenEJB, etc) is totally without any merit. 

    I agree with that indeed. To clarify myself, I too think that no serious web application can be build on just a plain Tomcat; meaning the Servlet container, a JSP compiler and the Java SE library.

    A very, very small web site might be build using only Tomcat. I'm talking about a basic 3 to 5 page web site that's really more a web site than a web app. IFF somebody would decide to use Tomcat for that (instead of the more typical PHP setup), then I respect that and won't try to persuade such a person into using Java EE.

    But if someone says all they need is Tomcat and then proceed to use Spring with it, then their original argument of needing 'only' Tomcat obviously wasn't correct.

    Personally I think that a large numbers of modern web applications will have something like the Java EE 6 Web Profile as a minimum requirement.

  73. We have all beat this horse to death.  The interesting thing for me is I have never understood the EJB fans. I think I am starting to see that experiences push these preferences to where they are.  I have only good experiences with Spring and only bad experiences with EJB. The other side seems to be diametrically opposite of this position. What really makes a developer a rockstar is the open mindedness to listen to both sides of the argument and be ready to say they need to investigate areas they don't understand and defend their side not with suppositions nor logical fallicies, but with real facts.

    Ultimately what matters is the set of experiences individually and of the team on a project's success not the technology itself. I can say I enjoy the minds and talent I encounter in environments that don't immediately embrace a certain technology stack.  My current employer has used nearly the full spectrum of choices and tries to use the right tech for the right problem.  I like this organic and flexible nature. I will say the EJB implementations, including a Seam app, have been less positive than the Spring implementations.

    The core arguments I see so far are:

    You say standardize APIs are important.  I say they don't matter as much. If you are a Spring app you are chosening that and not likely moving away from it.  You still hold the choice to go into any EJB container you want if necessary.  EJB implementations are standard for only so long.  Switching from one container to another will likely result in breaking changes that have to be adapted.

    I say any IoC framework/container brings about easier testing. I have really yet to hear the response on how to do this well in EJB. I do agree they are both containers the difference is who owns the Java process the app or the framework. This is why testing is easier with Spring or Guice.  I am actually starting to like the idea of inversing the embedding of the servlet container, yeah I know JBoss MC is available.  But first, let the Java process own more control of the web container and the Spring Context. This becomes even more inverted, maybe even more flexible.  I think if an EJB container can become more like this you would peak my interest. I should give a look at JBoss MC I have heard it isn't quite there yet but, I should find that out myself.

    You say Spring configuration is a painful, complicated, and requires specialization. I say no not really.  The talent is there without specialization. I have never meet a "Spring consultant" and don't see why it would be necessary.
  74. Jason,

    Frankly, it's patently obvious you know very little to nothing about anything outside Spring (your grossly outdated statements on EJB/Java EE/Seam testability are a great case in point - as I said, take a look at embedded containers, OpenEJB and JBoss Arquillian, not to mention my own article on EJB testability on TSS that's now more than a year old: http://www.theserverside.com/news/1363649/New-Features-in-EJB-31-Part-5).

    I've done quite a few Seam/Java EE projects at this point and not a single team would dream back to Spring for the reasons I've already mentioned. I've heard the same from anyone that I've talked to that actually uses Seam/Java EE 5/Java EE 6. It's sounds more as though you are here to defend your ill-researched decision to blindly jump on the Spring bandwagon that to actually listen, so please stop the nonsense about being supposedly open-minded. Try to be honest and admit that the choice to go the Spring route has little to do with technological merit and more to do with personal/political preferences, or worse, plain just ignorance or an unwillingness to try anything new.

    Do yourself a favor and actually do some homework next time before posting nonsense...

    Cheers,
    Reza
  75. Same old, same old...[ Go to top ]

    Jason,

    Frankly, it's patently obvious you know very little to nothing about anything outside Spring (your grossly outdated statements on EJB/Java EE/Seam testability are a great case in point - as I said, take a look at embedded containers, OpenEJB and JBoss Arquillian, not to mention my own article on EJB testability on TSS that's now more than a year old: http://www.theserverside.com/news/1363649/New-Features-in-EJB-31-Part-5).

    I've done quite a few Seam/Java EE projects at this point and not a single team would dream back to Spring for the reasons I've already mentioned. I've heard the same from anyone that I've talked to that actually uses Seam/Java EE 5/Java EE 6. It's sounds more as though you are here to defend your ill-researched decision to blindly jump on the Spring bandwagon that to actually listen, so please stop the nonsense about being supposedly open-minded. Try to be honest and admit that the choice to go the Spring route has little to do with technological merit and more to do with personal/political preferences, or worse, plain just ignorance or an unwillingness to try anything new.

    Do yourself a favor and actually do some homework next time before posting nonsense...

    Cheers,
    Reza
    This thread is totally a waste of time (and I actually read most of the comments).  It's interesting how any thread on TSS that's on Java EE app servers ends up becoming some stupid flame war on Spring vs. Java EE.

    Let them use Spring, who cares?  I've been using JBoss and EJBs since 2005 (3.2.0) and have had some minimal exposure to Spring 2.5 (JdbcTemplate).  My last two large companies are using the JBoss stack including EJB3, JSF, Hibernate, Seam, RichFaces and JBoss 4.2 AS.  There's a very brutal learning curve with this stack (and it may be worse with CDI/Weld) but I imagine the learning curve for the entire Spring application stack (including the overly-complex AOP) is brutal as well.

    Enjoy the wars...
  76. Irrespective of servlet container or Java EE app server, I would recommend the discussions in the Java EE community focus on productivity and performance concerns.

    For example, I have been using m2eclipse, Mylyn and JRebel in Eclipse recently.

    These surveys on who's using which app servers is just a waste of time to me.  Best thing is to download and try yourself in a clustered environment.

    btw, I don't think the JBoss docs are poor.  The Seam reference documentation is over 600 pages.  And Denis Golovin, Max Andersen of JBoss Tools team and the RichFaces devs (e.g. Ilya) typically respond to questions in the JBoss forums within 24 hrs.  Bravo!

    What does matter when choosing an app server vendor is support (SOC and SLA)...

  77. Guys, our team took another pass on the raw data from the survey and we've updated the results to take into account those who did not select JBoss but did select JBoss+Tomcat as a response. 

    Please have a look at the updated report here: http://info.replaysolutions.com/l/1772/2010-03-22/15B6T. 

    The original report stated the correct data as we had collected it, but the result was misleading if you only looked at the JBoss result without considering the JBoss+Tomcat responses. We've corrected that now by showing the total of both while not double-counting those who selected JBoss and JBoss+Tomcat.

    Thanks.
    Jonathan.

  78. That link didn't paste properly... here's the correct one:


    (Hope that works...)
    Thanks.

  79. That link didn't paste properly... here's the correct one:


    (Hope that works...)
    Thanks.

    The counts are still incorrect because you overcount for responses that include "TC + JB" and "Tomcat" - that should count 1 for Tomcat not 2.

    It's still strange to include aggregates on the same bar chart.


    - Rich
    JBoss, Red Hat

  80. You're right, and our results do not double count for users who said Tomcat and Tomcat+JBoss. Those are counted as 1 towards Tomcat. I believe our most recent numbers matched yours, Rich.

    I can understand the questions around the charts. We wanted to recognize that people often use more than one app server and make sure we showed that. We're not suggesting that the data directly represents market share, but for us it's interesting data. We wanted to share it with the community. 

    The results do accurately report the 1,100 responses we received. We did goof by not including GlassFish though!
  81. Genuitec from MyEclipse fame had a poll a while back and the results were a little different. See http://www.myeclipseide.com/Poll-8.html

    What's Your Favorite App. Server

    Tomcat   43 %43 %43 % 43.20 % (375)
    JBoss 25 %25 %25 % 25.46 % (221)
    WebLogic 11 %11 %11 % 11.87 % (103)GlassFish 7 %7 %7 % 7.03 % (61)Geronimo1 %1 %1 % 1.04 % (9)Jetty1 %1 %1 % 1.04 % (9)JOnAS0 %0 %0 % 0.69 % (6)JRun0 %0 %0 % 0.81 % (7)Oracle1 %1 %1 % 1.84 % (16)Resin1 %1 %1 % 1.73 % (15)WebSphere5 %5 %5 % 5.30 % (46)

    Hmmm, Preview on this site does not show what you *really* get after a post :(

    Let's try again:

    Tomcat 43.20 % (375)

    JBoss 25.46 % (221)

    WebLogic 11.87 % (103)

    GlassFish 7.03 % (61)

    WebSphere 5.30 % (46)

    Oracle 1.84 % (16)

    Resin 1.73 % (15)

    Geronimo 1.04 % (9)

    Jetty 1.04 % (9)

    JRun 0.81 % (7)

    JOnAS 0.69 % (6)


  82. Favorite vs. Using[ Go to top ]

    It's interesting to see what the response is when someone says 'what are you being forced to use at work' as opposed to 'what is your favorite.'

    WebSphere at 5%? Considering how bit its user base is, that's pretty dismal. :(

    Yeah...the preview...new system, and they're working on it.
  83. Favorite vs. Using[ Go to top ]

    It's interesting to see what the response is when someone says 'what are you being forced to use at work' as opposed to 'what is your favorite.'

    Indeed, this would be rather interesting. Have the same interview ask for:

     * What AS do you use for development and/or testing?
     * What AS do you use in production?
     * What is your favorite AS?

    I would hope that most people would be able to give the same answer for all three questions, but maybe in practice this wouldn't always be the case.

  84. Genuitec from MyEclipse fame had a poll a while back and the results were a little different. See http://www.myeclipseide.com/Poll-8.html

    What's Your Favorite App. Server

    Tomcat   43 %43 %43 % 43.20 % (375)
    JBoss 25 %25 %25 % 25.46 % (221)
    WebLogic 11 %11 %11 % 11.87 % (103)GlassFish 7 %7 %7 % 7.03 % (61)Geronimo1 %1 %1 % 1.04 % (9)Jetty1 %1 %1 % 1.04 % (9)JOnAS0 %0 %0 % 0.69 % (6)JRun0 %0 %0 % 0.81 % (7)Oracle1 %1 %1 % 1.84 % (16)Resin1 %1 %1 % 1.73 % (15)WebSphere5 %5 %5 % 5.30 % (46)

    Hmmm, Preview on this site does not show what you *really* get after a post :(

    Let's try again:

    Tomcat 43.20 % (375)

    JBoss 25.46 % (221)

    WebLogic 11.87 % (103)

    GlassFish 7.03 % (61)

    WebSphere 5.30 % (46)

    Oracle 1.84 % (16)

    Resin 1.73 % (15)

    Geronimo 1.04 % (9)

    Jetty 1.04 % (9)

    JRun 0.81 % (7)

    JOnAS 0.69 % (6)


  85. Favorite vs. Using[ Go to top ]

    It's interesting to see what the response is when someone says 'what are you being forced to use at work' as opposed to 'what is your favorite.'

    WebSphere at 5%? Considering how bit its user base is, that's pretty dismal. :(

    Yeah...the preview...new system, and they're working on it.
  86. Favorite vs. Using[ Go to top ]

    It's interesting to see what the response is when someone says 'what are you being forced to use at work' as opposed to 'what is your favorite.'

    Indeed, this would be rather interesting. Have the same interview ask for:

     * What AS do you use for development and/or testing?
     * What AS do you use in production?
     * What is your favorite AS?

    I would hope that most people would be able to give the same answer for all three questions, but maybe in practice this wouldn't always be the case.