Java Champion / JavaOne Rockstar Adam Bien (adam-bien.com) is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector. He is also the author of several books and articles on Java and Java EE technology, as well as distributed Java programming. adam has posted 59 posts at DZone. View Full User Profile

Java EE 6 xor Spring

09.13.2010
| 10355 views |
  • submit to reddit

I get asked over and over again about my opinion about Spring "vs." Java EE. There is no "vs." rather than "xor". Java EE 6 is similar to Spring. Java EE 6 comes even with the JSR-330 - a Dependency Injection specification led by Rod Johnson. The main difference between Java EE and Spring is the "philosophy" behind. Java EE 6 does follow the "Convention over Configuration" or "Configuration by Exception" idea - what appears for Spring guys as Voodoo (had a long on-stage conversation with Juergen Hoeller just about that) e.g. EJB 3.1 are "just" transactional without any further ceremony. Spring on the other hand relies on explicit configuration. "Convention Over Configuration" vs. explicit configuration, however, never decided in my projects, which platform to use.

The "support" or "maintenance" policy question made the decision in last few years. It seems like developers and managers don't even know, that Spring comes with well defined SpringSource Enterprise Maintenance Policy. You will have either to upgrade to the current version of Spring (read the policy for more details), or buy a support contract. Both are valid approaches - your sponsor / manager / client just have to know about that.

There are similar policies for Java EE servers as well - so your management will have to decide which contracts to buy - or whether to go with unsupported system into production. Regardless how well it may or would work, this is not a development, rather than "political" / "strategic" decision. Given that both platforms are rather similar it is just crazy to buy both contracts.

If you go with Spring - I would use the supported tc Server: Lightweight Application Server for Cloud and Virtual Environments. It comes with nice out-of-the-box experience and professional support from single vendor.

I would always prefer the tc Server, over "custom" Tomcat+Spring configurations...

From http://www.adam-bien.com/roller/abien/entry/java_ee_6_xor_spring

Published at DZone with permission of its author, adam bien.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

And Bod replied on Tue, 2010/09/14 - 2:59am

God you say alot of crap. You're the dude who like 5 posts ago wondered what's the use of coding to interfaces (you didn't put it like that, you were using some "down to earth" bla such as why do Service s = new ServiceImpl()). And now this crap. What exactly are you saying? Because it just looks like alot of bla to me, which:

 

a. firstly it doesn't say anything useful about anything. You just waste space. You say "alot of people asked you...". Are those "alot of people" like more than 100 000 so that you feel the need to answer them in a public channel like that? Or are you just trying to impress your girlfriend?

 

b. how exactlly is java ee 6 more "convention over configuration" than spring (3 or even 2.5.6)?  Spring MVC, Spring WS, Spring LDAP, the IOC container all contain sensible defaults that you only alter if you need to.  Here, let me remind you of what you just wrote:

EJB 3.1 are "just" transactional without any further ceremony. Spring on the other hand relies on explicit configuration.

 

Um, what? The sky is blue BUT I have a round pebble?

 

c. I'm not even gonna explain to you on how many levels you are wrong asking why coding to interfaces is useful , I mean, it's not like the whole java ee is based on it.

 

And no, just because you have a fancy title doesn't mean you actually know what you're talking about. I've seen dozens of "gurus" say the most stupid things, generally in public. Bruce Eckel's superb diatribe on why java exceptions are bad comes to mind right now. Remember that one, where he forgot the difference between checked and unchecked exceptions (or, rather that unchecked exceptions exist)? 

 

Here's something for you, lend it to Bruce when you're done, ok?

 

http://www.amazon.com/SCJP-Certified-Programmer-Java-310-065/dp/0071591060/ref=sr_1_1?ie=UTF8&s=books&qid=1284451290&sr=8-1

Wujek Srujek replied on Tue, 2010/09/14 - 3:09am in response to: And Bod

I don't aggree with all that you have just said, I aggree with one thing, though - Adam says a lot of useless crap, he has been for some time now (I didn't read him before, so maybe it has always been like this). And I hate the EE 6 preaching, how simple it is and so on. It looks like he has never really written any serious app using it, just toys; for anything more complex than that, it is pretty damn difficult but only due to the amount of bugs (GlassFish 3.x, JBoss 6) which Adam seems to ignore.

Ignorance is bliss.

Mladen Girazovski replied on Tue, 2010/09/14 - 6:34am

Hi Adam, good food for thought as usual.

Personally i preffered using Spring together EJB 2.x  in the same Projects, since they did complement each other.

 With JEE 5/6 of course, there are even more of the same aspects covered in both, making some things redundant.

There are similar policies for Java EE servers as well - so your management will have to decide which contracts to buy - or whether to go with unsupported system into production. Regardless how well it may or would work, this is not a development, rather than "political" / "strategic" decision. Given that both platforms are rather similar it is just crazy to buy both contracts.

 The thing is, our customers usually expects my company to support the SW we deliver, including all the SW Infrastructure needed (App Servers and so on), so we still can use both, cherry picking the features that we need.

adam bien replied on Tue, 2010/09/14 - 8:31am in response to: And Bod

@And,
I'm not even gonna explain to you on how many levels you are wrong asking why coding to interfaces is useful , I mean, it's not like the whole java ee is based on it.
I really encourage you to write a short article (e.g. at dzone) about the value of the pattern:
Service s = new ServiceImpl(). But: please be constructive. I'm really looking forward to it. I guess the editors will accept that.
It is hard to respond to your comment :-). A few remarks:
  1. What "title" do you mean? I don't have any...
  2. I do not post on dzone. The editors asked me to copy some content from my blog. This happens without my knowledge.
  3. I get asked about Spring everytime I mention Java EE. How often? I would say > 50 times a year.
Keep on commenting! :-) (better write some constructive posts), thanks, adam

Ronald Miura replied on Tue, 2010/09/14 - 8:35am

Hey, your Spring bashing is getting more refined! It's not the "Spring is not a standard, so it's bad" anymore. Instead, now you disguise your talk as it was a perfectly neutral and unbiased opinion, giving pros and cons, hiding all your FUD.

EJB 3.1 are "just" transactional without any further ceremony

They couldn't do that, because it would break previous behavior. Instead, they created a new type of bean (@Singleton), and added this 'convention' on it. That is, different kinds of EJBs now have different transactional behavior conventions. You're right, Spring doesn't do that. Instead, it gives you mechanisms to do that if you want:

@Inherited
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
@Scope("singleton")
@Transactional
public @interface Singleton {
}

If you go with Spring - I would use the supported tc Server: Lightweight Application Server for Cloud and Virtual Environments. It comes with nice out-of-the-box experience and professional support from single vendor.

I would always prefer the tc Server, over "custom" Tomcat+Spring configurations...

Fear, Uncertainty and Doubt. "It's very good that you can get support from a single server for your proprietary framework, don't even try using it without this!" Crap, crap, crap.

Spring will work nice in any server that supports Servlets. And that means any Java app server. Since it depends only on servlets, the possibility of hitting some incompatibility between servers is minimal (now compare this with the situation where you depend on whatever versions of whatever implementations of JPA, CDI, EJB and JSF are in the server's classpath. I've never heard of anyone who cares about 'API portability' more than 'server portability'.

So, you don't need a tcServer. You probably don't need commercial support either, but if your boss need it (to have peace of mind), many vendor will give you support on this. Here in Brazil, even RedHat/JBoss sells support for Spring (well, if they don't, they won't have many customers).

Also, putting this decision on the 'political and strategic' sphere, you also diminish the fact that they are technical decisions! Yes, if you ask a manager if she prefers a supported framework or a unsupported framework, the answer is obvious, but that is not the right question, nor she is the right person to be asked. You don't ask the CEO if you may or may not use commons-lang.

That's not to say that you should never use EJB (3.0+. You should never use EJB 2.x or below) or CDI. Maybe your company already have a long-time contract with RedHat. Maybe all your programmers know EJB 3, but don't have much experience with Spring (that means, they don't have much experience in anything). Maybe you just believe that EJB is technically superior. And also believe in Santa Claus, Easter Bunny, and Tooth Fairies...

Ronald Miura replied on Tue, 2010/09/14 - 8:47am in response to: And Bod

Adam surely says lots of crap (justified, since he lives by the whatever-comes-out-from-JCP-is-better-since-im-a-Java-EE-consultant book), but you talk shit just as much.

Coding to interfaces is about 'interfaces, the concept', not 'interface, the Java reserved keyword'. It's about coding to the contracts a class exposes, instead of its inner implementation.

That said, Adam could only now argue against interfaces for every bean (which I wholeheartedly agree with), since until EJB 3.0 the use of interfaces for every bean is mandatory. :)

adam bien replied on Tue, 2010/09/14 - 8:49am in response to: Wujek Srujek

...written any serious app using it, just toys; for anything more complex than that, it is pretty damn difficult but only due to the amount of bugs (GlassFish 3.x, JBoss 6) which Adam seems to ignore...
Please be more specific. What do you mean by ignoring? I opened approx. 30 cases in Glassfish v1-v3 (search for abien here: https://glassfish.dev.java.net/issues/query.cgi). Don't worry - most of them are fixed already. Even blogged about that: Why You Should File Bugs - The Glassfish Case

What problems (bugs) do you have specifically?
But more interestingly: what is your opinion? Does support not matter to your customers?

adam bien replied on Tue, 2010/09/14 - 9:20am in response to: Ronald Miura

That said, Adam could only now argue against interfaces for every bean (which I wholeheartedly agree with), since until EJB 3.0 the use of interfaces for every bean is mandatory. :)
not true:-)

Ronald Miura replied on Tue, 2010/09/14 - 9:37am in response to: adam bien

I don't get it, the example in your post does have an interface...

Reza Rahman replied on Tue, 2010/09/14 - 11:06am

Adam,

I know how you feel - I've been asked this question numerous times myself and even finally attempted to provide an answer with code examples: http://www.redhat.com/f/pdf/jbw/rrahman_320_spring_framework.pdf. Personally, I think people should be taking these as input and drawing their own conclusions.

And of course I experience the same thing you see here - that you must be the devil incarnate if you suggest that Spring is anything but manna from heaven when it is crystal clear that it has it's own unique set of trade-offs as most technologies do.

Do yourself a favor and ignore the blatant flames for what they are and simply address the technical points (as you are)...and keep up the good work :-).

Cheers,

Reza

Reza Rahman replied on Tue, 2010/09/14 - 11:04am in response to: Ronald Miura

Ronald,

What Adam is trying to say is that EJB 3.1 does not require interfaces. Take a look here: http://www.adam-bien.com/roller/abien/entry/will_ejb_3_1_ioc. Personally, I think overusing interfaces is a little "old school". This is not a "political" statement, simply an observation just as overusing XML, annotations, DI or any other potentially pervasive construct is usually a bad idea...

Cheers,

Reza

Josh Marotti replied on Tue, 2010/09/14 - 11:21am in response to: And Bod

what's the use of coding to interfaces (you didn't put it like that, you were using some "down to earth" bla such as why do Service s = new ServiceImpl()). And now this crap. What exactly are you saying?

 

I checked the article in question.  He wasn't saying not to code to interfaces, but the poor naming conventions used by implementations, and, honestly, I completely agree with him.

List list1 = new ListImpl();

So... is that an ordered list?  Array list?  What happens when you make another implementation?  What are you going to call it?  ListImpl2?

What he's saying is to drop the whole 'Impl' and make a descriptive name:

List list = new ArrayList();

See what he means?

Wujek Srujek replied on Tue, 2010/09/14 - 12:00pm in response to: Ronald Miura

<cite>Maybe all your programmers know EJB 3, but don't have much experience with Spring (that means, they don't have much experience in anything).</cite>

Are you serious?

Ronald Miura replied on Tue, 2010/09/14 - 1:28pm in response to: Josh Marotti

@Josh

I also agree that meaningful names are better.

But in this post, he starts the argument around the "Impl" suffix convention, but all the cons he enumerates are about the very existence of the interfaces, not their naming:

  1. Imagine you get another implementation (thats the whole point of an interface) - how would you name it?
  2. It doubles the amount of artifacts - and significantly increases the "complexity"
  3. It is really funny to read the javadocs on the interface and the impl - another redundancy
  4. The navigation in the IDE is less fluent

Well, but my complain on this was not to Adam, but to 'And Bod'. DZone's UI doesn't make it very clear who I'm replying to...

Ronald Miura replied on Tue, 2010/09/14 - 1:51pm in response to: Wujek Srujek

@Wujek Shrek
Maybe all your programmers know EJB 3, but don't have much experience with Spring (that means, they don't have much experience in anything). Are you serious?

Yes, I'm serious. Follow me:

  • Before EJB3, EJB wasn't even a viable option for most projects, so everybody used Spring instead.
  • If you are a developer from before EJB3, you're certainly had some experience with Spring (or, suffered the terrible pains of deploying EJB1/2, using xdoclet to generate interfaces and XML files, and you have my sympathy).
  • If you don't know Spring, chances are that you became a developer after EJB3 was released.
  • Since EJB3 isn't that old (about 3 years old), you probably are not a very experienced developer (by my standards).

But, Ok, the world is big, and I don't know how things went there in India. I take back my words.

adam bien replied on Tue, 2010/09/14 - 2:53pm in response to: Josh Marotti

@Josh, exactly! If:

List list1 = new ListImpl();

Were the only only implementation I would delete the interface, rename the ListImpl() to List() so it would looks like:

List list = new List();

...and if there were several implementations, no-one would name one of them Impl....:-) Thanks!

Reza Rahman replied on Tue, 2010/09/14 - 3:31pm in response to: Ronald Miura

Ronald,

I'm not quite sure what you think India has to do with it, but a vast majority of EJB 3/CDI developers here in the US are former Spring developers or use Spring on some projects.

Hope it helps,

Reza

samuel mansoor replied on Tue, 2010/09/14 - 4:44pm

I think this argument can go on and on. I like spring it helped me with some major projects where we needed light weight container and in some instance we needed ejb (2.1) with session bean and MDB. Both had their own pain with transaction. In case's of ejb things ran much better on wls 9.x from 8.1, wls supports spring. I still would prefer ejb over spring due to fail over, redundancy, and JTA. Its not that spring cannot support JTA. arg ok both are good but ejb 3 changes the game. Btw I am a big fan of interface and design pattern . I have seen some enterprise application source code where design pattern where not implement it was a total disaster. thanks Sam

Liam Knox replied on Tue, 2010/09/14 - 5:49pm in response to: Reza Rahman

I think you are both missing the point on the mocking side here. If you use Mockito you have to design for extension and therefore are immediately opening your API up anyway. So what is better having an interface and a final implementation or allowing a developer to extend a class you wanted to make final but coudln't due to test reasons?

Doesn't seem like a great clear solution to this. I am sure there are a few patterns out there but no doubt these add more bloat and complexity. My real thought though is that as with all encapsultation in general Java's current model is too weak

Ronald Miura replied on Tue, 2010/09/14 - 6:59pm in response to: Reza Rahman

That's what I'm talking about! Experienced developers are almost guaranteed to have some experience with Spring.

Grzegorz Grzybek replied on Wed, 2010/09/15 - 12:55am

There's been some time since good Spring vs. JavaEE thread :)

 @Adam

What "title" do you mean? I don't have any...

It's about this "XOR" - you suggest that with Spring/JavaEE it's always "either/or". That's the problem with JavaEE IMO - I'm using Spring since 2004 and I'll quote what I'm always saying:

Our production system works since late 2004. It then used Spring 1.0.2. Now it's using Spring 3.0.4 and we haven't changed anything except replacing "class" with "(class)" in one property file. It still works. The only problem was during migration from WebSphere 5 to 6 - the problems were with ... JSPs, taglibs and MDBs.

First - we don't use MDBs anymore, second - the migration problems made the customer decide to not migrate to WebSphere > 6 ever.

I don't say "I'm using Spring" - I'm using JavaEE's pieces which I like with the help of Spring products in the areas of: security, MVC, DI, Integration, Messaging.

If only Velocity was more tool-supported (only syntax highlighting and code-completion) I would use that instead of JSP as a view-templating technology.

I just don't agree with your "XOR" - Spring makes it easier to work with Servlets (core JavaEE api) building a nice MVC framework on top of it. Sorry but I'm the "web applications are template-based" not "web applications are component-based" guy, so JSF (been there, tried to make advanced dynamic apps with that) are not for me. JSF is good (IMO) for "guess the number" games. Spring makes it possible to implement advanced Security requirements (JavaEE - don't) - two LDAPs anyone? Spring is predictible! It has well defined Maven repository artifacts with clean source code repository - there's only one "spring-core-3.0.4-sources.jar" - I can count at least dozen of "servlet-api-2.5.jar" and with JavaEE6 it's only worse (see: http://www.restfusion.com/blog/2010/02/jee-sdk-loathe-it-or-ignore-it-you-cant-like-it/comment-page-1/#comment-33, http://in.relation.to/Bloggers/AHitchhikersGuideToJavaEE6ApplicationSetupPartI#comment15759).

Now we're over 9 months since JavaEE 6 final release. According to http://java.sun.com/javaee/overview/compatibility.jsp there's still only GF (the RI) and TMAX JEUS (the what?). On bare Tomcat I can use everything I want from JavaEE6 (and some of it I like) - JAXB2.2, JSF2 (just an example), JAX-WS, JPA2 - I pack all I want into WEB-INF/lib and voila! I just can't use JSP 2.2/Servlets 3.0 (with Velocity I couldn't just use Servlets 3.0 because it would make JSP 2.2 unnecessary).

My experience with JavaEE is that it has single, most influencial API which really changed Java Enterprise programming - the Servlets API. JavaEE 6 adds asynchronous servlets and annotations (basically), but who really needs servlets annotations? Do you really write servlets these days? I usually use few (actually one) existing - Spring's DispatcherServlet. JPA2? Hibernate has this "binding", but I use just Hibernate (3.6.0.beta4) - I changed the version whenever I want and I don't care what version my "app server" provides.

In "JavaEE vs. Spring" discussions there was also one thought - that "one should use separate instances of app servers for different applications - http://www.adam-bien.com/roller/abien/entry/future_of_enterprise_java_is#comment-1269351084306) - so why "big" app servers? One of my (working in production) projects used Spring-Integration running as (Tanuki) service with embedded Jetty - it had all I want from JavaEE - JPA, JAXB, web services, security, JSP, servlets, JMX, mail, JMS.

Conclusion - I think "JavaEE guys" want everyone to stick to "javax.*" packages, optionally with CDI extensions (after 9 months - are there any interesting, not Seam-based?). I'm a "Spring guy" and I think that one should use whatever is appropriate for the problem. In one real-world project I tried to use JSF, but ended up with huge, UIComponent operating methods, just to implement some semi-complex dynamic form. Then I just used JSP to generate the required WWW interface, added JQuery and everything now works. JavaEE (without anything external) is too-academic, too up-front based (here - on 10th Dec 2009 we gave you THE way of writing enterprise apps - thou shall use it!). Spring just makes enterprise programming much easier.

regards

Grzegorz Grzybek

Steve Hicks replied on Wed, 2010/09/15 - 2:29am

I have been using Spring since 1.X after using EJB 2 for several years and while EJB 3 looks a major improvement I do not see it being any better. That said, the differences nowadays are much smaller. For me, some of the extra benefits with Spring are (I am sure others will have more):

1.) I do not see anything equivalent to Spring Security in the JEE stack

2.) I can test my Service methods (where I do workflow logic with DAO) without deploying my application (our target application server is WebLogic)

3.) I can upgrade the framework without upgrading WebLogic (OK with JEE plugable architectures this might not always be an issue)

4.) For smaller developments, Spring Roo gives a really fast solution. Again no JEE equivalent

5.) You can view Spring code within your debugger (WebLogic was closed the last time I needed to check - but that was a while ago)

However, I think that having a choice between the two is really good for innovation and hence for me developing Java applications and Adam's point on thinking about what support you require is something not to ignore - even if you are happy to support any problems that come out of Spring yourselves.

adam bien replied on Wed, 2010/09/15 - 7:29am in response to: Steve Hicks

However, I think that having a choice between the two is really good for innovation and hence for me developing Java applications and Adam's point on thinking about what support you require is something not to ignore - even if you are happy to support any problems that come out of Spring yourselves.
The essence of my post is: Java EE 6 is similar to Spring 3. So it is really crazy to deploy Spring 3 to a Java EE 6 container. The best choice would be to use the TC server from SpringSource or use a standalone Java EE 6 server. Why TC-Server? Because it was built by SpringSource - so I would start with that. I would also prefer Glassfish over e.g. Tomcat + openEJB + mojarra + EclipseLink + openMQ + Grizzly + etc. patchwork.

Ronald Miura replied on Wed, 2010/09/15 - 9:14am

@Adam

So it is really crazy to deploy Spring 3 to a Java EE 6 container.

No, it's not 'crazy'. It works, and works well. The whole point is that Spring doesn't require a Java EE 6 container to run, it will work with pretty much whatever you've got.

So, if you want more app server portability, using Spring is not a crazy idea at all, but using EJB 3.1, which requires the latest and greatest app servers, would probably be.

adam bien replied on Wed, 2010/09/15 - 9:53am in response to: Ronald Miura

It isn't logical to me. I would use TC but not a full Java EE 6 server to put Spring on top of it. I know it is possible and works well. But - why?

Reza Rahman replied on Wed, 2010/09/15 - 9:53am

Steve,

It sounds as though you haven't looked around the Java EE 6 ecosystem too much (understandable if you have been doing solely Spring develoment for a period of time).

* Seam has had an excellent security module that works with Java EE since Java EE 5. With Seam 3, the security module will work with any CDI compliant container.

* You could do out-of-container testing with embedded containers like OpenEJB since Java EE 5. With Java EE 6, that has been improved even more with making embedded containers mandatory for all containers (including WLS) and well as excellent application-server agnostic testing tools such as JBoss Arquillian.

* Spring Roo has an equivalent in Seam tooling such as seamgen that works with Java EE and is being imoroved even further with Seam 3/Java EE 6. As you noted though, it is also the case that Spring Roo has a relatively narrow use case as such.

* It is true that WLS is closed-souce but of course there are great open source Java EE implementations out there.

* As you mentioned, a majority of Java EE APIs are now pluggable and most people using open source Java EE application servers do upgrade quite frequently without problems.

Hope it helps,

Reza

Steve Hicks replied on Wed, 2010/09/15 - 10:27am in response to: Reza Rahman

Where I work is not going to change from WebLogic anytime soon

 So when we upgrade to a WebLogic upgrade to JEE6 it will be closer but them is it a choice of Seam versus Spring and will I get full Seam support from Oracle?

 I must admit that when I read Dan Allen's Seam book it do look very interesting but I was put off using it from a combination of being very happy with Spring and reading some problems on the WebLogic forum of people using Seam (that was version 2).

Reza Rahman replied on Wed, 2010/09/15 - 10:49am in response to: Steve Hicks

Steve,

It is doubtful Oracle will support Seam 3 modules for WLS, but they will support their CDI implementation which will likely be JBoss Weld. I can't speak to using Seam on WLS since I haven't done it myself. I do know it works very well with JBoss AS, GlassFish and WebSphere. Not sure how much experience you've had with JBoss support but generally JBoss does have very good community and commercial support as compared to most companies.

Hope it helps,
Reza

Reza Rahman replied on Wed, 2010/09/15 - 11:25am in response to: Grzegorz Grzybek

Grzegorz,

The decision to choose a standard, pre-configured Java EE stack vs. compiling one on an ad-hoc basis I think is a pragmatic one as opposed to anything irrationally based as you seem to be suggesting. It saves time and energy in configuration and let's you focus on the business problems at hand. It also minimizes dependence on any particular vendor or code-base.

Now, that's not to say that the choice to compile your own stack is irrational either. It can make sense for a variety of projects, organizations and individuals. After all there are still people out there that compile their own Linux distribution starting from a kernel :-) (in case you missed the humor here, using Spring is certainly not as bad as that).

Cheers,
Reza

Ronald Miura replied on Wed, 2010/09/15 - 2:00pm in response to: adam bien

It isn't logical to me. I would use TC but not a full Java EE 6 server to put Spring on top of it. I know it is possible and works well. But - why?
  • Because companies are often very conservative about server upgrades: we still use JBoss 4.2.3 and JDK 1.5 where I work. Most places I've worked were always one or two versions behind the latest server/JDK. Java 8 will probably be already out when we are able to adopt Java EE 6.
  • Because we (developers) rarely have a say in choosing a new app server: in organizations where there is one almighty architect, he may have the power to make the choice. Where there's none, some director/manager will buy from the best salesman.
  • Because often our apps must run on whatever server our client has: if you sell software, the one who buys it will want to run it on his existing infrastructure (which may be heterogeneous even internally). If you limit your options to the latest and greatest, you will lose many potential clients.
  • Because having a server-portable app gives you more flexibility when choosing your infrastructure: if your application runs on a broader range of server vendors/versions, you have much more options, and the testing/approval cycle will be much shorter. Or even run it on the cloud! :)

You may not agree with all statements above, but I'm sure I'm not being illogical. Illogical is assuming that the only logical choice of app server when using Spring is the tcServer.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.