Is Tomcat 7 in your future?

Discussions

News: Is Tomcat 7 in your future?

  1. Is Tomcat 7 in your future? (14 messages)

    I’ve been following Tomcat 7 development for some time now and I've been asked recently why (and when) clients should upgrade to Tomcat 7, now that it’s nearing release (currently targeted for “late summer”). So, I’ve started to give some thought to that question. I have to admit, the answer wasn’t immediately obvious either way. I’m going to split this blog into two parts; the first with my views and very preliminary results of my testing and evaluation. The second will be based on an interview scheduled for this Wednesday with one of the senior Apache Tomcat “committers”.

    Note: In Apache Speak, a Committer is selected by his peers to be trusted to make changes to the code base. In a mature and extremely widely used project like Tomcat, this is very hard to achieve and carries great responsibility.

    When I think about “upgrading”, I immediately think about two quite different scenarios.

    1. Upgrading existing infrastructure for production environments. “If it works, why mess with it?” surely applies.
    2. Selecting the infrastructure for new projects. “Should I really base my critical new project on a dot-zero infrastructure release?” is usually my first thought.

    We’ll explore both situations, focusing on both Tomcat 7’s stability as a “dot-zero” release and what new capabilities Tomcat 7 brings to the table.

    Tomcat 7 is the first major Tomcat release in quite a long while (three and a half years…and counting), since Dec 1, 2006 when Tomcat 6.0 was released. Tomcat 7 Beta was released on June 29th (YEA!) and a large number of people have already downloaded that snapshot to evaluate (or beat on) it.

    Stability

    Let’s first talk about stability. I believe that it’s important to consider the differences between conventional commercial software products (where I wouldn’t take a dot-zero into production for anything, and I am often reluctant to even try it out) and Open Source, where I assert the situation can be very different. A major difference between these is in development/testing methodology.

    Commercial Software

    Commercial software is thoroughly tested by QA organizations during development and as the release draws to closure. Tests are a performed by a combination of automation for repetitive tasks and manual for things rapidly changing and/or too difficult to automate. Tests are written by QA Engineers and are (almost always) designed to prove the feature does what’s its spec says it should do. Only rarely is there sufficient budget/time (or inclination) to indulge in the opposite, which is to try all the things it shouldn’t do, or in other words: to trash it. That also requires a particular mentality, all too rare in QA organizations. Corporate pressure is “make sure it works”, not “try to prove it doesn’t work”. There is also little/no "use case" testing, particularly for infrastructure products, due to the difficulty of creating or obtaining sufficiently broad and complex use cases.

    At some point in time the software is deemed “Beta” and released, typically to a very small number of carefully selected and closely managed accounts. Almost always, this process is driven by Marketing/Sales, and in many cases Beta is actually managed by them. In my experience running software products and software development organizations, I’ve rarely seen anything come out of Beta testing that benefitted the product…that’s not what the Beta process was really being used for.

    So, commercial software products ship with extensive “prove the features work” testing and virtually no “prove the product solves the customers business problems” testing. Sad, but true. The result is a dot-zero release has had almost no actual use when it hits the street. So, we avoid it at all cost, particularly if we value our jobs!

    Open Source Software

    In sharp contrast, Open Source projects are available to whomever wants to grab them and beat on them, through virtually the entire development cycle. Nowhere is there a contact that says “you can have this, play with it a bit so we can claim we’re getting close, but you absolutely positively MUST NOT try to really use it”. I’ve seen Open Source projects successfully find their way into production, and even into commercial products, well before they ever “get released”. This is a valuable part of the hardening process and it’s up to the users to determine their level of risk…not a vendor.

    There are also those engineers that take great delight in finding and exposing flaws in their peers work, whether through breaking it functionally or through exhaustive code review/analysis. This also is a valuable (though it can be hard on the ego…I still remember a submission I did to a OS project a number of years ago, which got loudly...and publically trashed) part of the hardening process and I’ve never seen that behavior allowed, much less encouraged, in a commercial environment.

    Finally, only in OpenSource does the user have access to the entire release defect log, bugs found, bugs fixed, and even the source code to do their own use case debugging.

    So, an active Open Source project has been subject to:

    1. An extended period of real world “use case testing”, without artificial bounds
    2. Some (typically less than a commercial product) “does the feature work” testing
    3. A large number of smart eyes, many of whom are looking for a better way to do things and some of whom take great delight in breaking things by subjecting them to abuse that’s way beyond that found in the real world.

    For these reasons, my experience with dot-zero (and closely following) releases of mature Open Source projects has been very different than it with commercial products…either mine or others. I’m much more confident that open source projects have been subject to review (torture?), beyond anything I might do (I still do my own testing, of course) and that a community of very smart people has exercised due diligence for their own purposes.

    So, I’d make the claim that I NEVER take/recommend a dot-zero for a commercial infrastructure product and I FREQUENTLY take/recommend a dot-zero or dot-zero + release of a mature Open Source infrastructure product.

    In the case of Tomcat 7, if the new features offer me benefit for my new project, I’d be inclined to use it and move forward, although with due caution and the understanding that I'm participating in a community hardening effort. For my current production environments, I’d be somewhat more cautious, although I could make the case to upgrade if it was sufficiently easy to do so (more about that later) and if I saw significant benefit from the new capabilities for my old application. In both cases, I wouldn’t let fear of dot-zero-itis control my decision.

    Note: My (limited) experience to date is that Tomcat 7 is at least as stable as the Tomcat 6 versions that I’ve been building applications on for a number of years. That said, I've only experienced one production use and two test cases, so this is VERY preliminary.

    Functionality

    As I noted above, Tomcat 7 has lots to like. This includes, but is certainly not limited to, full support for the Java Servlet 3.0, JSP 2.2, and EL 2.2 specifications. TC 7 makes it even easier to create ever more complex web applications, including lots of bundled features that we’d have to implement or find third party solutions for. It also improves Tomcat’s already impressive performance and efficiency, which is particularly important in today’s distributed service (and increasingly virtualized) deployment architectures.

    Another area that I’m excited about is Tomcat 7’s improved memory leak prevention/detection. Many developers tend to blame Tomcat for their application memory leaks, partly because Tomcat did have some issues in its early days and developer memories are very long and partially because Tomcat did very little to enforce or detect memory leakage in the client code. Basically you had to check server logging, which is FAR more difficult in horizontally scaled, services based, virtualized, deployments…perhaps even impossible.

    Many of my clients also pair Tomcat with SpringSource, creating a “SpringSource Server” that is both performant and reliable. TC 7 makes Tomcat an even better platform for frameworks such as Spring.

    Servlet 3.0. Servlet 3.0 improves ease of development, extensibility, and security. It also adds support for asynchronous programming techniques.

    • Asynchronous Support. Servlet 3.0's asynchronous support has been fully implemented in TC 7. There was async programming in Tomcat 6, but Servlet 3.0 support offers developers a standard interface, improving portability between containers.
    • Dynamic Configuration. Another Servlet 3.0-related feature is Tomcat 7's dynamic configuration functionality. Tomcat 7 provides support for web fragments, so libraries can use an embedded web.xml fragment for configuration, eliminating the need to add library-specific configuration entries to application's web.xml files.
    • Annotation Support. Tomcat 7 also includes Servlet 3.0's new annotation support, offering developers a way to configure filters, listeners, and servlets using declarative style programming. Classes and servlets can be quickly defined by annotating the class, which makes development faster and eliminates the need for deployment descriptors.
    • Extended Servlet API. An extension of the Servlet API enables the programmatic addition of Filters and Servlets when an application starts. Although access to this API while running an application is prohibited in the Servlet 3.0 specification, Tomcat 7 will allow developers to ignore this somewhat controversial limitation if they wish, at the expense of portability.
    •  More Servlet 3.0 Features. Other features that developers will appreciate include the use of generics, improved session tracking and SSL session ID tracking for increased security. Also included is a brand new file upload functionality, which will allow developers to upload additional libraries as needed.

    Additional Tomcat 7 Features. The fun with Tomcat 7 doesn’'t stop with the Servlet 3.0 specification support. Also included are are:

    •  Simplified Embedding. Tomcat 7 includes an API that makes embeddable Tomcat applications a simple, hassle-free reality. Utilizing this new API, developers only need a few lines of code to get Tomcat running within their applications.
    •  Improved Logging. Tomcat 7 includes two improvements to its logging system: a single line log formatter to make log files easier to read and an asynchronous file handler. The single line formatter writes logs in a single line, which makes life much easier for IT admins. The asynchronous handler allows Tomcat to write logs to disk in a dedicated thread, so that logging operations do not cause any latency in processing threads.
    •  Aliases. This new feature allows inclusion of external file systems or Web Application Archive content within an application, such as images or JavaScript directories, so that shared assets can be centrally distributed across a wide array of web applications. In today’s deployment architectures, this is hugely powerful.
    •  Memory Leak Detection/Prevention. Although the bugs in Tomcat's 4.1.x/5.5.x codebase responsible for some of these errors have long been fixed, developers still had trouble eliminating memory leaks caused by their own applications. Tomcat users have historically had problems with memory leaks when reloading web applications throughout the existence of the project, usually manifesting as an OutOfMemoryError for the Permanent Generation. The Tomcat team has been frustrated from time to time by applications that continue to adversely affect perceptions of Tomcat’s reliability. So, they decided to enhance Tomcat to be able to deal with many of the application defects that caused memory leaks. They were able to track down and repair a number of bugs specific to certain Java APIs and they wrote patches for the most common application-caused memory leaks. Applications which previously triggered these leaks can now reload without error and new applications will be covered as well.
    •  Improved Security. The Manager and host-manager applications have been made more secure, by splitting privileges into multiple roles. Tomcat 7 also includes blocking to prevent tampering with the Session ID (sometimes called session fixation attacks). There are also now separate roles for script-based, web-based, JMX proxy, and status page access, for more specific access control.

    Upgrading

    As I noted above, I’ve been playing with Tomcat 7 for some time. I’ve also tried moving a few applications from Tomcat 6. I didn’t avail myself of Servlet 3.0, so my experience so far is more of a “upgrade existing application” rather than “develop new application” scenario. See http://tomcat.apache.org/migration.html  for help when you start this process and also see Mark Thomas’s blog for some additional info.

    •  OS/Environment. I ran the Tomcat 7 upgrades on RHEL 5 and Java 6. I had some difficulty building Tomcat 7, but I never really figured out why. Suddenly, it just worked, so it may have been pilot error.
    •  Tomcat Manager. I personally find Tomcat Manager more trouble than not. I really prefer the commercial management products (such as vmWare/SpringSource and MuleSource, although for very different reasons). That said, I did muddle thru the Tomcat 7 Manager just to see what I thought. The biggest change I found in manager is that manager has been split into multiple console segments, each with its own URL (enabling more detailed privilege management). These are the Web Interface, the Text Interface, the JMSProxy/Servlet, and the Server Status page(s). Each now also has a specific Manager Role associated with it and host manager has likewise been split into multiple roles. This should improve management security, although no where near as much as the aforementioned products.
    •  Deployment. This is one of the bigger changes in administration, because the most commonly used deployment—context descriptors contained in WAR files were extracted and deployed into the containing Host's xmlBase— is no longer the default behavior. You can apparently re-enable this if you wish, but for the purpose of the experiments, I did not.
    •  Application Behavior. Porting these three applications to Tomcat 7 was pretty straightforward. In the first case, the application “just worked” once I got it deployed and in the second case, I needed to do some tweaking of the configuration. In the last case, I needed to do some recoding because of the use of Hibernate. I haven’t ported any Spring Based applications, but I expect those will go similarly easily…and probably better where additional services such as data persistence are utilized.
    •  Application Performance/Reliability. I’ve not done any stress testing yet, but my first impressions are that the applications are at least as stable and just a touch faster. One of the applications—that happens to be well instrumented— runs about 8% faster with Tomcat 7.

    Conclusion

    Would I use Tomcat 7 for a new mission critical application? Possibly, depending mainly on the benefits of Servlet 3.0 and the schdule for the application release and I might wait for a point release or two. Would I upgrade existing running applications to Tomcat 7? Not yet, unless there were compelling functional reasons to take that risk. Once again, it would depend somewhat on the schedule. Of course, if my existing application had problems (for example, having to be re-started every few weeks because it ran out of resources), then I would at least try Tomcat 7 to see if it caught my application problem.

    I’d be very interested in hearing about your experiences and hear your thoughts.

     

     

     

    Reposted from TomcatExpert.com: http://www.tomcatexpert.com/blog/2010/07/29/tomcat-7-your-future

  2. Okay, I'm really loath to do this, but the comments in this thread really started to get out of line, and I think everyone reading it could agree that people were starting to post comments in the heat of the debate that were a tad too personal. Eventually, so much stuff gets posted that it distracts from the debate, and everyone involved eventually gets embarrassed by being associated with the thread. This thread really hit that point and beyond.

    I think as Java professionals, we maintain a higher standard with regards to the types of comments and threads with which we want our names associated. So, for the sake of posterity, I've removed all the comments associated with this thread, so everyone has a clean slate, and nobody will accuse me of any bias for keeping certain comments and deleting others.

    Having said that, I'm amazed by how many great comments were in so many posts. Clearly TSS readers had taken a great deal of time to organize their thoughts, and there was some seriously insightful and researched comments made. Of course, as too often happens in these online forums, a great response was a tad tarnished by an off topic quip. And I do understand that most of these were probably intended as 'friendly baiting' comments, we all know that sarcasm and 'friendly baiting' is often lost in the 'inflectionless' medium of the online forum.

    The bulk of the comments were simply too good to delete forever, so I'm going to go over the entire thread and just clean it up and repost an article that reflects the sentiment on all sides.

    I know it burns everyone's a** to see posts they put together deleted. Please give me that latitude to rework the thread and repost it on TheServerSide in a way that reflects the intellect and debate that ran through the thread, and not the less desirable things that made their way into it.

    -Cameron McKenzie

    Editor in Chief, TheServerSide.com

     

  3. I Got It...[ Go to top ]

    DA & RR, I got both of the feedback comments you sent me regarding this, and thanks!

  4. I'm looking forward to reading the new article.  There were a couple of things I didn't say that maybe you could include in the new article.

    1) Someone listed a couple job links that show "Java Spring" being miles ahead of "Java EE":

    http://www.indeed.com/q-java-Spring-jobs.html

    http://www.indeed.com/jobs?q=Java+EE&l=

    The numbers are reversed if you compare "Java Spring" with "J2EE". 

    http://www.indeed.com/q-java-Spring-jobs.html

    http://www.indeed.com/jobs?q=J2ee&l=

    Combine "J2EE" with "Java EE" and get even higher numbers:

    http://www.indeed.com/jobs?q=J2ee%2C+Java+EE&l=

     

    2) I linked to a GlassFish pricing page, but the link doesn't work.  The actual link is:

    https://shop.oracle.com/pls/ostore/product?p1=OracleGlassFishServer

     

  5. I'm looking forward to reading the new article.  There were a couple of things I didn't say that maybe you could include in the new article.

    1) Someone listed a couple job links that show "Java Spring" being miles ahead of "Java EE":

    http://www.indeed.com/q-java-Spring-jobs.html

    http://www.indeed.com/jobs?q=Java+EE&l=

    The numbers are reversed if you compare "Java Spring" with "J2EE". 

    http://www.indeed.com/q-java-Spring-jobs.html

    http://www.indeed.com/jobs?q=J2ee&l=

    Combine "J2EE" with "Java EE" and get even higher numbers:

    http://www.indeed.com/jobs?q=J2ee%2C+Java+EE&l=

     

    2) I linked to a GlassFish pricing page, but the link doesn't work.  The actual link is:

    https://shop.oracle.com/pls/ostore/product?p1=OracleGlassFishServer

    Hi Ryan,

    Look what I came up with as well.  The picture/graphical story of the tech usage numbers:

    http://www.indeed.com/jobtrends?q=J2ee,+java+ee&l=

    http://www.indeed.com/jobtrends?q=J2ee,+java+ee,+java+Spring&l=

    http://www.indeed.com/jobtrends?q=java+ee,+java+Spring&l=

    http://www.indeed.com/jobtrends?q=java+ee,+java+Spring,+Cobol&l=

    http://www.indeed.com/jobtrends?q=java+ee,+java+Spring,+Cobol,+j2ee&l=

    What do you make of those five comparisons?

    I'm thinking J2EE, and Cobol are older than Spring and Java EE, and hence they may be in maintenance phases now, and will not be really used to implement any significant number of new projects but rather primarily maintain older/existing projects.

    I think Spring and Java EE are what we would be using for new projects.

  6. Doug,

    With all due respect, a lot of Java EE and Spring customers still refer to their projects as "J2EE" simply because it is a more recognized term.

    Cheers,

    Reza

  7. Doug,

    With all due respect, a lot of Java EE and Spring customers still refer to their projects as "J2EE" simply because it is a more recognized term.

    Cheers,

    Reza

    I agree Reza. The semantics involved where customers/users sometimes refer to Java Spring apps as J2EE apps (assuming we are speaking in the strict sense of what J2EE means) can get things a bit hazy when looking at how the adoption rate trends of strict Spring apps, strict Java EE x apps, and strict J2EE apps stack up against each other. 

    Thrown into that confusion is the fact that Spring is sometimes meshed into the systems that are by their very nature either strict J2EE or strict Java EE x environments (i.e. standard J2EE/Java EE application servers).  

    In trying to tease out the actual trends of what seems to be happening with strict J2EE apps, strict Spring apps, and strict Java EE x apps, we could however make the following assumptions when looking at the progressing direction of the curves shown on this graph http://www.indeed.com/jobtrends?q=java+Spring,+J2EE,+Java+EE&l=
    , bearing in mind that the indeed.com data set may not be an accurate reflection of the usage trends of these technologies in the real world.

    Further assumptions:

    1) We could assume that the three curves represent trends for strict J2EE usage/apps, strict Spring usage/apps, and strict Java EE usage/apps.

    In this regard, the direction of the curves seem to still be in line with my earlier assumptions made to Ryan about usage of the technologies for maintenance purposes as opposed to implementing new systems/projects.

    2) We could also take the assumption that customers/users have a decent understanding of the fact that despite semantic gray areas in usage of the terms J2EE, Java EE, and Spring, that they pretty much know that Java EE is differnet from J2EE, even if we assume that they throw Spring in the mix when talking about J2EE.  In the latter regard, two top curves of Spring + J2EE are still above the Java EE curve, and hence still tells a story about the usage/adoption rate of Spring.

    3) We could also assume that based on the slope of the three curves, it seems that over an extended period of time, the Spring curve may either intersect, or intersect and surpass the position of the J2EE curve at a faster rate than the Java EE curve which seems to be meandering onward on a flat path since its last point of inflexion.

    The points of supposedly likely intersection of the Spring curve and the J2EE curve should basically be the point at which we compensate for the semantic gray area in which we could assume Spring is likened unto J2EE in loose speaking terms - however, for the point at which the Spring curve just goes above the J2EE curve since the point of intersection, that is the point where the we know usage trends probably indicate strict Spring systems as opposed to strict J2EE systems.

    4) Finally, if we would like to tease out the trends of trying to see if Spring is primarily being used in J2EE projects based for maintenance phases as opposed to being used for new project implementations, the following graphs below seem to indicate a rising slope of the Spring curve in all/significant number of cases illustrated, when overlayed with with the many application server implementations (i.e. strict servlet based, J2EE based, and Java EE x based implementations). We see that all usage patterns (i.e. maintenance and new project implementations/green field) are covered by the Spring technology with Spring being at the top of all the curves in most cases.

    http://www.indeed.com/jobtrends?q=Glassfish,+Caucho+Resin,+Tomcat,+JBOSS,+Websphere,+Weblogic,+Jetty,+Spring,+ejb+3&l=

    http://www.indeed.com/jobtrends?q=spring,+tomcat,+glassfish&l=

    http://www.indeed.com/jobtrends?q=spring,+ejb+3,+glassfish,+tomcat&l=

    http://www.indeed.com/jobtrends?q=spring,+tomcat,+ejb+3,+glassfish,+jboss&l=

    ---------------------------------

    Please note that these are all just assumptions based on the context of the data presented by indeed.com on technology trends only.

    The real world may be saying something totally different.

  8. Some additions[ Go to top ]

    Cameron,

    I am a little uncomfortable doing this because it feels like typical self-aggrandizing/marketing, but this might be helpful: http://www.caucho.com/products/pricelist/? I would qoute the JBoss and Geromino commercial support prices too but they are not easy to get to. Maybe the Geronimo/JBoss guys can help to keep things fair and balanced?

    Kindest regards,

    Reza

  9. Hi guys,

    A thought just popped into my head to check what indeed.com had to say about how a couple of app servers stack up against each other.  

    This may not be an accurate reflection of what's really happening in the app server market space, but it's interesting to see that for commercial app servers, with prices varying from the near dirt cheap, to the ones being sold for moderately expensive, or higher, the prices don't seem to affect the customer adoption rate.

    Also of note is that Tomcat and JBOSS seem to be real contenders among them all.  Both those app servers seem to be hovering in the "Goldy Locks" zone of app servers.

    Check it out:

    http://www.indeed.com/jobtrends?q=Glassfish,+Caucho+Resin,+Tomcat,+JBOSS,+Websphere,+Weblogic,+Jetty&l=

    http://www.indeed.com/jobtrends?q=Caucho+Resin&l=

    http://www.indeed.com/jobtrends?q=Glassfish,+Caucho+Resin&l=

    http://www.indeed.com/jobtrends?q=Glassfish,+Caucho+Resin,+Tomcat&l=

    http://www.indeed.com/jobtrends?q=Glassfish,+Caucho+Resin,+JBOSS&l=

  10. Hi guys,

    A thought just popped into my head to check what indeed.com had to say about how a couple of app servers stack up against each other.  

    This may not be an accurate reflection of what's really happening in the app server market space, but it's interesting to see that for commercial app servers, with prices varying from the near dirt cheap, to the ones being sold for moderately expensive, or higher, the prices don't seem to affect the customer adoption rate.

    Also of note is that Tomcat and JBOSS seem to be real contenders among them all.  Both those app servers seem to be hovering in the "Goldy Locks" zone of app servers.

    Check it out:

    http://www.indeed.com/jobtrends?q=Glassfish,+Caucho+Resin,+Tomcat,+JBOSS,+Websphere,+Weblogic,+Jetty&l=

    http://www.indeed.com/jobtrends?q=Caucho+Resin&l=

    http://www.indeed.com/jobtrends?q=Glassfish,+Caucho+Resin&l=

    http://www.indeed.com/jobtrends?q=Glassfish,+Caucho+Resin,+Tomcat&l=

    http://www.indeed.com/jobtrends?q=Glassfish,+Caucho+Resin,+JBOSS&l=

    Guys, I left something out in the analysis even though it should be obvious to you anyway.

    To be fair, Weblogic, and Websphere are ahead of the pack when compared to all the other app servers shown - and those are app servers that people pay to use.

    So I guess Websphere and Weblogic might have other things going for them here, such as longevity/maturity, quality, branding, and efficient pricing when compared to what the market will be willing to pay for those products if you look at things from the view of the optimum pricing to set on a price curve drawn on a demand vs supply graph (i.e. elementary economics).

  11. Job trends are always interesting to look at and a good indicator of what's being used, although they don't have much weight in my decision making process.  We used to run JBoss in production which is by far more popular than GlassFish, but ultimately we ended up switching to GlassFish for its administation capabilities and time to market with the latest Java EE specs.  The monthly usage maps and mailing list activity show me that it is still very widely used:

    http://maps.glassfish.org/server/

    http://markmail.org/search/?q=list%3Anet.java.dev.glassfish.users

    Anyhow, this is supposed to be about Tomcat.  No, Tomcat 7 will not be in my future but I'm sure it will still be widely adopted.  There's definitely a market for Tomcat, and SpringSource is smart to capitalize on it.

     

  12. Ryan,

    Could not agree more on the relative unimportance of adoption rate/job-trend snap-shots. If they really were that important, we would see technology mono-cultures and Java is anything but that…

    Besides the ones you pointed out, there are a whole host of other issues with simply looking at "Java EE" and "Spring" as job trend keywords. Here are a few, roughly in order of relative importance:

    1. Spring predates Java EE, which means that there is a natural adoption lag for Java EE. It also means that Java EE is likely to have higher statistical growth rates in the near term, just as Seam, Guice, JSF, JPA, Wicket, you-name-it-emerging-java-technology.

    2. A large amount of "Spring" jobs are maintenance projects just as "J2EE" jobs are. It's shocking really how many Spring 2.0 or J2EE 1.4 jobs there are out there.

    3. Java EE projects sometimes will only have EJB 3, EJB3, Seam or EJB as keywords. A very recent project I was offered only had JBoss ESB and EJB3 as keywords. I've come across a fair number of state, local and federal jobs over the years that often only have EJB and WebSphere as requirements whereas they really are Java EE jobs and not J2EE jobs. Similarly there is a gamut of local JBoss shops that really see Java EE projects simply as Seam projects (and somewhat rightfully so).

    All that being said, I think it's fairly obvious Spring jobs outnumber Java EE jobs. Anecdotally speaking, I would say I come across about 30% Java EE green-field projects and 70% green-field Spring projects. Now, granted there is a strong element of self-selection there since I have decent relationships with local recruiters, have a decent existing Java EE client base and can often justify/influence technology choices as an architect.

    Still, I think those are pretty decent indicators even accounting for all the common mis-conceptions about Java EE/J2EE and the fact that we have a pretty compelling new stack with Java EE 6 and another one being developed in Java EE 7.

    At the end of all that, I do agree Tomcat has a bright future and wish nothing but the very best for Spring/SpringSource...

    Cheers,

    Reza

  13. Great...So Many Angles[ Go to top ]

    Okay, I can see this is going to be a full time job aggregating all of this stuff. I'll make it a feature article.

    I'm starting to think that maybe it'd just be easier if I wrote a definitive article that finally decides which is better - PC or Mac. :)

    I'll get at it!

     

  14. Great...So Many Angles[ Go to top ]

    Okay, I can see this is going to be a full time job aggregating all of this stuff. I'll make it a feature article.

    I'm starting to think that maybe it'd just be easier if I wrote a definitive article that finally decides which is better - PC or Mac. :)

    I'll get at it!

     

    It looks like this thread has finally come to an end, with no winners or losers.

  15. Great...So Many Angles[ Go to top ]

    Ryan,

    I think you hit the nail on the head :-). If this stuff was really that cut and dry to have sports or formal debate style "winners" and "losers" it would not be that contentious in the first place, not to mention it would be rather intellectually boring :-).

    Cheers,

    Reza