Discussions

News: Salil Deshpande: Spring is the new Java EE

  1. Salil Deshpande, ex-CEO of The Middleware Company, attended TheServerSide Java Symposium after a long hiatus. He shares his perspective and experience – this article is partly human-interest and partly technical. The primary conclusion: Spring is the new Java EE version.
    The Spring phenomenon though, is too big to not end the article dwelling on it again. Spring will be integrated with OSGi during the remainder of 2007, Rod Johnson said in his talk on Spring 2.0. OSGi is a dynamic module system for Java, something that should have been part of Java from the beginning. Strangely, it is currently pervasive on the client side due to Eclipse (plugins), but not well known on the server side. The Spring-OSGi integration is likely to make it into OSGi standards. And as a testament to Spring’s decoupled pieces-parts architecture, Spring itself is available as OSGi bundles. Longer term, the Spring Framework is turning into the Spring Portfolio. There are integrations with JCA, CICS, and IMS. There’s Spring Web Services, and Spring LDAP. Message-driven POJOs will become possible with Spring. Acegi, the leading enterprise-grade Java security framework, is becoming Spring Security. There’s Spring Web Flow, which is just what it sounds like, again with POJOs. The role of Spring in SOA is being standardized with efforts such as the Service Component Architecture (SCA). A Spring IDE (implemented as plugins for Eclipse) which will support Spring development, including support for AOP, and Spring Web Flow, is in the works. Perhaps most important is the fact that Interface21 plans to bundle this large collection of little parts that make up the Spring platform or portfolio, and make them available as a single download …or distro. Not just parts all slapped together, but tested and integrated, with the right versions, known to work with each other. I believe this will clinch it. Enterprise Java will mean Spring. Last but not least, next generation application servers from BEA, and maybe IBM, will be built on top of Spring. Am I the only one that finds this mind-blowing?

    Threaded Messages (61)

  2. Excellent retrospective and analysis, Salil! I've been a long time believer that JEE is nice as a reference implementation but that reality overcomes its perceived benefits. The people working on JEE tend to be way over cautious and pedantic, whereas people coming up with other products (Mule, Spring, Hibernate) succeed because their focus is on solving a specific problem well, usually under production pressures, and many times ignoring the dogmas that come with having to comply with JEE or other specifications. It'll be interesting to see where Spring heads now that it's become the Big Kid on the Block. I personally prefer its implementation over JEE, and it's my impression that the cloud of vendors around Spring are more focused on solving problems than the JEE guys, who seem to be focused only on complicating things more so they can keep selling more software and professional services. Cheers, E
  3. I agree with what Eugene said, I'd also like to point out that when creating a web based framework like Struts, the JavaEE (Oh hell J2EE) API shouldn't bleed into the developers code. If you want an example, look at Struts 1.x . Do you really care about the HttpServletRequest or the HttpServletResponse object when writing components for Struts? Remember the Unix motto: 'Do one thing and do it well'. Best Regards, Richard L. Burton III
  4. The lightweight JEE container[ Go to top ]

    lightweight EJB3=spring+pitchfork+openJPA superb transactions--> atomikos or jotm u wanna WS* --> add CXF wanna security (real world and configurable)--> add acegi wanna clustering and caching -->add terracotta web support--> jetty+(choose ur favourite framework) and many more.... we donot need the JEE specs,we donot need the JCP, SUN,please let the community lead the platform and it will be much much better world
  5. Can anyone explain?[ Go to top ]

    When I read this article, I got stuck here:
    As an aside on the two general unrelated topics of copying good ideas from .NET, and suddenly realizing that things sucked: there was general consensus among speakers and panelists that when Sun copied generics from .NET, they traded off the most important feature (type erasure) in the name of backwards compatibility. Now a Java programmer a look at a piece of supposedly well-written Java code, and legitimately have no friggin’ idea what it does.
    Maybe I'm reading into this but it reads to me like he's saying that type-erasure makes code hard to understand. If that's true, I don't really see how it's the case.
  6. Re: Can anyone explain?[ Go to top ]

    When I read this article, I got stuck here:


    As an aside on the two general unrelated topics of copying good ideas from .NET, and suddenly realizing that things sucked: there was general consensus among speakers and panelists that when Sun copied generics from .NET, they traded off the most important feature (type erasure) in the name of backwards compatibility. Now a Java programmer a look at a piece of supposedly well-written Java code, and legitimately have no friggin’ idea what it does.


    Maybe I'm reading into this but it reads to me like he's saying that type-erasure makes code hard to understand. If that's true, I don't really see how it's the case.
    I would like to add even more here. As far as I remember correctly SUN and MS worked on generics independly. It's funny to said that SUN copied generics from .NET, since as far as I know java generics were released on September 2004 (together with JSE 5.0) and .NET generics were release (together with .NET 2.0) on September 2005, rouhgly a Year after java generics... Artur
  7. Re: Can anyone explain?[ Go to top ]

    When I read this article, I got stuck here:


    As an aside on the two general unrelated topics of copying good ideas from .NET, and suddenly realizing that things sucked: there was general consensus among speakers and panelists that when Sun copied generics from .NET, they traded off the most important feature (type erasure) in the name of backwards compatibility. Now a Java programmer a look at a piece of supposedly well-written Java code, and legitimately have no friggin’ idea what it does.


    Maybe I'm reading into this but it reads to me like he's saying that type-erasure makes code hard to understand. If that's true, I don't really see how it's the case.
    I have to agree. This sort of statement does not inspire confidence.
  8. lightweight EJB3=spring+pitchfork+openJPA
    superb transactions--> atomikos or jotm
    u wanna WS* --> add CXF
    wanna security (real world and configurable)--> add acegi
    wanna clustering and caching -->add terracotta
    web support--> jetty+(choose ur favourite framework)
    and many more....
    we donot need the JEE specs,we donot need the JCP, SUN,please let the community lead the platform and it will be much much better world
    yepm
  9. Uh, Spring = Plumbing[ Go to top ]

    Spring is no where near being the next "JEE". And you're completely dreaming if you thing thats true. The Spring/Interface21 guys have done absolutely nothing "new", they haven't really innovated on top of JEE in any way shape or form. They've provided one thing, and one thing only: Plumbing. Now I'm not going to argue anything about the quality of thier plumbing, just that fact that thats all it is - plumbing. A lot of it is also nothing special - I don't see how conveinience annontations and pre built classes rate as the new "JEE".
  10. Re: Uh, Spring = Plumbing[ Go to top ]

    Because j2ee by itself has traditionally ..well - sucked? j2ee/ejb 1-2 - suck suck suck -> enter hibernate -> life is better , j2ee still sucks -> enter IoC / Spring -> life is even better, services testable -> j2ee still sucks
    ...Now I'm not going to argue anything about the quality of thier plumbing, just that fact that thats all it is - plumbing. A lot of it is also nothing special - I don't see how conveinience annontations and pre built classes rate as the new "JEE".
  11. Re: Uh, Spring = Plumbing[ Go to top ]

    Hibername + spring + webwork, rocks sudhir http://www.jyog.com
  12. Spring is no where near being the next "JEE". The Spring/Interface21 guys have done absolutely nothing "new", they haven't really innovated on top of JEE in any way shape or form. They've provided one thing, and one thing only: Plumbing.
    Right, Spring has no containers in the sense of JEE. But in the midst of the (hopefully running out) hype people even see things that aren't there. It reminds me of the heated discussion in the 90ies whether Java would replace Windows.
  13. Spring is no where near being the next "JEE". The Spring/Interface21 guys have done absolutely nothing "new", they haven't really innovated on top of JEE in any way shape or form. They've provided one thing, and one thing only: Plumbing.

    Right, Spring has no containers in the sense of JEE. But in the midst of the (hopefully running out) hype people even see things that aren't there. It reminds me of the heated discussion in the 90ies whether Java would replace Windows.
    I think there is some confusion here because of the dual meaning of JEE. JEE can either be thought of as the "umbrella" specification that plumbs all the other JEE specifications (EJB, JMS, etc) together, or as the sum of all these specifications. The proposition that Spring would, in itself, replace all the implementations of the specifications which it is primarly designed to plumb together, is pretty far fetched. On the other hand, the proposition that Spring might, at some point, become an umbrella itself, with such market penetration that it becomes a de facto standard with better penetration than the umbrella standard itself might be more realistic, even though I personally dont believe so. Flame me.
  14. Spring is no where near being the next "JEE". And you're completely dreaming if you thing thats true.

    The Spring/Interface21 guys have done absolutely nothing "new", they haven't really innovated on top of JEE in any way shape or form. They've provided one thing, and one thing only: Plumbing.

    Now I'm not going to argue anything about the quality of thier plumbing, just that fact that thats all it is - plumbing. A lot of it is also nothing special - I don't see how conveinience annontations and pre built classes rate as the new "JEE".
    Plumbing as defining a uniform component model is a very hard thing to achieve while being very important. Spring with is IoC container, AOP engine and portable abstractions have succeeded quite nicely at it. My opinion is that Spring is becoming more and more the standard component model and that JEE servers should focus on providing services instead of frameworks/container. Leave the frameworks/container development to the open source community, just provide so some sort of standard way to expose your object to external protocols as HTTP,RMI,JMX, ... There are way too much innovation going on to expect a standard specification to be able to follow up. The only thing that would be necessary is a way to orient new comers to the platform. Maybe a web site tracking the major open source efforts, I don't know.
  15. I am less than convinced that Spring will make it to the mainstream simply because it will not enjoy the deployment adoption that JEE has achieved, through its infancy and on to current status in v.5. JEE solves the only really pressing issue in corporate IT: standardize on something non-Microsoft. Spring is at best an afterthought in the decision of what to make corporate IT decisions upon... I wouldn't be surprised to see Spring and SCA get some support from all Java vendors, but its main beneficiaries are those that are trying to unseat Sun, albeit currently unsuccessfully, as the IT manager's choice for a heterogenuous environment. WebLogic and WebSphere product teams will continue to jump on any bandwagon that suggests that Java's demise is imminent: first SOAP, then Spring, now SCA - - it just ain't going to happen... As has been seen with JBoss and the 'portfolio' that it embraces and supports, there is truly a need for an enterprise vendor to step up and standardize on the implementation, not just the development environment. This is JEE's true strength, that it captures Java developer's needs while also continuing to be the deployment environment that corporate IT can feel comfortable with, and standardize on. Anything that will strike corporate IT as an ad hoc project will most likely remain niche status, and will not be welcomed as a platform on which to implement large-scale integration projects, in the form of enterprise-wide. JEE has been doing this for at least 5 years, Spring has not done it yet. Sure, Rod can come on here and throw case studies at me, but its not pervasive, its not ubiquitous, and its not stable enough to standardize on, and I don't just mean technical stability... Unless IBM re-writes WebSphere according to Spring, there will be no day that this Internet message board will ever be the competitor for JEE that so many claim, hope, and ultimately can't deliver on. Its fun, its like cheering for the underdog blindly while the favorite continues to improve, gain momentum, and adapt - - ultimately inertia sets in and you move to the next great thing. Keep it up, i say to the Spring believers, but don't throw away the true alternative to singular hegemony, unless you are one of those that are truly scared of Glassfish monopolies...
  16. Spring is already mainstream[ Go to top ]

    Whether you like it or not, Spring is already mainstream. I'm not the typical Spring fanboy, I don't particularly like WebFlow for instance, but Spring has convinced me that standards don't matter. This webapp called JTrac, which I develop in my spare time uses Wicket + Spring + Hibernate. No annotations are used at all. I don't need EJBs for transactions, Spring takes care of that. Jetty is the default app server and without the need for JSP (because of Wicket) the app server footprint is ~1.3 MB. App starts and stops in seconds. There are JUnit tests that work with an HSQLDB database created on the fly, no need for DAO mocks. I find Hibernate criteria queries amazing and cannot understand why there is no support for criteria queries in the JPA spec. I find JSF a pain to use and openly wish it suffers the same fate as the EJB2 spec. Why is there a lot of fuss about things like Glassfish? As a developer, I get all the "enterprise" stuff I need with a 1.3 MB app server and the Spring and Hibernate JARs. Please don't give me the "standards do matter" line - would appreciate hearing more compelling arguments.
  17. Whether you like it or not, Spring is already mainstream. This webapp called JTrac, which I develop in my spare time uses Wicket + Spring + Hibernate.
    Completely agreed. Spring is a perfect container and Wicket is a great web framework which provides a really component oriented development. I'd also add DWR to the mainstream stack for AJAX development. And last but not least, evaluating Spring sources is like reading a poetry comparing to opensores JSF and Java EE implementations. Regards, Fyodor Kupolov Make ETL Easier - Use Scriptella
  18. I find JSF a pain to use and openly wish it suffers the same fate as the EJB2 spec.
    From http://www.computerworld.com.au/index.php/id;1005597423;pp;2;fp;4194304;fpid;1 "The benefit of that is that JSF provides a standard component model for Java Web development," said Johnson. JSF is becoming increasingly popular and serves as an alternative to the more traditional template-based approach to Web development, he said.

  19. "The benefit of that is that JSF provides a standard component model for Java Web development," said Johnson. JSF is becoming increasingly popular and serves as an alternative to the more traditional template-based approach to Web development, he said.
    Yes, we all remember the days when Entity Beans were getting "increasingly popular".
    But when it comes to the requirements of building real-world enterprise systems, characteristics like scalability, maintainability, robustness and guaranteed future weigh more than a set of nice features.
    Plenty of Spring case studies for this.

  20. "The benefit of that is that JSF provides a standard component model for Java Web development," said Johnson. JSF is becoming increasingly popular and serves as an alternative to the more traditional template-based approach to Web development, he said.

    Yes, we all remember the days when Entity Beans were getting "increasingly popular".
    I reckon the I21 guys were hurt by their initial rejection of JSP. This time they might be overly cautious about another “standard” monster (aka JSF). Or are they just another vendor in the JSF space?
  21. Re: Spring is already mainstream[ Go to top ]

    As a developer, I get all the "enterprise" stuff I need with a 1.3 MB app server and the Spring and Hibernate JARs.
    Believe it, or not, but all that "enterprise stuff" isnt really there for the developer. There is a very long road to travel for the small app developed in the garage (borrowing from Brooks) to reach the deepest server halls of a large corporation. A lot of stuff which seems totally wasteless in the garage might come in handy somewhere along the path.
  22. Spring is at best an afterthought in the decision of what to make corporate IT decisions upon...
    One could say that progress and evolution of ideas is nothing but a series of afterthoughts.
  23. Re: the model does not scale[ Go to top ]

    Spring is at best an afterthought in the decision of what to make corporate IT decisions upon...


    One could say that progress and evolution of ideas is nothing but a series of afterthoughts.
    I'd wished I had that afterthought.
  24. Surprise Surprise Surprise...another article and discussion on whether Spring is better than JavaEE. The fact is that JavaEE and Spring aren't mutually exclusive. They can work side by side. True there are some annoying things about JavaEE (AOP and EJB 3 springs to mind!) but both technologies can exist in harmony. I once asked Rod Johnson if Spring was going to replace J2EE and he said that Spring was a layer to improve the development of J2EE applications. JavaEE and Spring will make enterprise application development easier with a greater return on investment. With the two technologies developers can go to their PMs or managers and say with confidence how long a piece of development will take (compared to the old days of J2EE development). Don't get me wrong I'm not saying Spring is bad or anything. I am a great fan of Spring (will be attending this year's SpringOne woo hoo!) and have been developing Spring applications since 2005 and I have to say Spring rocks. Spring + Hibernate + AspectJ + OSGi is a cool combination in my opinion. I think Spring is pretty much here to stay. The integration with OSGi is an interesting area that developers should keep an eye on.
  25. Java EE is a standard[ Go to top ]

    There is a single fact why Spring is definitely NOT the new Java EE: Java EE is a STANDARD Spring is NOT Spring might be handy for some development scenarios, I have already been doing Spring projects for myself. But when it comes to the requirements of building real-world enterprise systems, characteristics like scalability, maintainability, robustness and guaranteed future weigh more than a set of nice features.
  26. There is a single fact why Spring is definitely NOT the new Java EE:

    Java EE is a STANDARD
    Spring is NOT

    Spring might be handy for some development scenarios, I have already been doing Spring projects for myself. But when it comes to the requirements of building real-world enterprise systems, characteristics like scalability, maintainability, robustness and guaranteed future weigh more than a set of nice features.
    I'm afraid i'm going to have to quote Peter Thomas (if that's ok Peter)
    Please don't give me the "standards do matter" line - would appreciate hearing more compelling arguments.
    Are you saying you can't build scalable, maintainable , robust enterprise applications using Spring? How do I put this.... have you heard of VOCA? Major investment banks developing front end applications using Spring? I'm not sure i can agree with on what you've just said.
  27. But when it comes to the requirements of building real-world enterprise systems, characteristics like scalability, maintainability, robustness and guaranteed future
    Yep, exactly what Spring is about and why we are happily using Spring in a entreprise szenario. ... And where we failed terribly ....albeit being a standard... with a EJB 2 based approach. Oh ok, now it's EJB 3 - altogether a different shoe and yes it's THE standard.... till the next revision?
  28. Spring case studies[ Go to top ]

    But when it comes to the requirements of building real-world enterprise systems, characteristics like scalability, maintainability, robustness and guaranteed future weigh more than a set of nice features.
    http://www.bejug.org/confluenceBeJUG/display/PARLEYS/Voca%2C+a+Spring+case-study Anyway i hope the Spring guys would work further on the configuration to make it much more simpler. To quote Jack Welch "You should never be done looking for a better way".
  29. Re: Java EE is a standard[ Go to top ]

    But when it comes to the requirements of building real-world enterprise systems, characteristics like scalability, maintainability, robustness and guaranteed future weigh more than a set of nice features.
    That's pure FUD, stop it.
  30. Re: Java EE is a standard[ Go to top ]

    There is a single fact why Spring is definitely NOT the new Java EE:

    Java EE is a STANDARD
    Spring is NOT

    Spring might be handy for some development scenarios, I have already been doing Spring projects for myself. But when it comes to the requirements of building real-world enterprise systems, characteristics like scalability, maintainability, robustness and guaranteed future weigh more than a set of nice features.
    Really comic, expecially "guaranteed future". If it was not tragic too. Guido.
  31. Re: Java EE is a standard[ Go to top ]

    I don't that categorizing my post as FUD or comic is a serious way of argueing. And please don't take the words I've used so exactly, I'm not a native english speaker so something like "guaranteed future" for cannot be taken for 100% -- but I assumed everybody of you should be able to understand what I meant. I'm not sure that I was able to express my thoughts correctly. From the viewpoint of an ISV accepted industry standards DO MATTER. I clearly didn't say that Spring is not a good product, if you read my comment you should know that I actually used it for myself already. I just wanted to say that there are scenarios and requirements where Java EE is the choice over Spring *just* because it is an accepted industry standard and Spring is not. Not because Java EE is that much better or Spring is not able to scale well etc etc. If you believe it or not - I already HAD the experience and I already WAS involved in projects where decision makers hung up their choice between 2 quite comparable frameworks/technologies (like Spring and Java EE) just on fact that on of them was an accepted industry standard. And that one was chosen - just for this reason.
  32. Re: Java EE is a standard[ Go to top ]

    I don't that categorizing my post as FUD or comic is a serious way of argueing. And please don't take the words I've used so exactly, I'm not a native english speaker so something like "guaranteed future" for cannot be taken for 100%

    -- but I assumed everybody of you should be able to understand what I meant. I'm not sure that I was able to express my thoughts correctly.

    From the viewpoint of an ISV accepted industry standards DO MATTER. I clearly didn't say that Spring is not a good product, if you read my comment you should know that I actually used it for myself already. I just wanted to say that there are scenarios and requirements where Java EE is the choice over Spring *just* because it is an accepted industry standard and Spring is not. Not because Java EE is that much better or Spring is not able to scale well etc etc.

    If you believe it or not - I already HAD the experience and I already WAS involved in projects where decision makers hung up their choice between 2 quite comparable frameworks/technologies (like Spring and Java EE) just on fact that on of them was an accepted industry standard. And that one was chosen - just for this reason.
    I think there are already quite many posts in this thread pointing out that Spring and JEE are not "2 quite comparable frameworks/technologies". JEE is a specification. Spring is a framework which works on top of implementations of JEE specifications.
  33. Re: Java EE is a standard[ Go to top ]

    What if something exists that is better than the so-called standard? What if the alternatives make life easier for a developer and are better suited to getting your project delivered on time? Someone already brought up the example of Struts being widely adopted despite not being a standard. If everyone had blindly stuck to the standard, Entity Beans would be still around and Hibernate would have fallen by the wayside. Don't let some "decision makers" who have no clue about technology make decisions purely based on what is the "standard". It is not always easy, but we have to try. I like to think that nowadays developers are having more say in these kind of decisions because of more information through blogs, this kind of discussion etc. Or maybe I'm just imagining things.
  34. Re: Java EE is a standard[ Go to top ]

    There is a single fact why Spring is definitely NOT the new Java EE:

    Java EE is a STANDARD
    Spring is NOT

    Spring might be handy for some development scenarios, I have already been doing Spring projects for myself. But when it comes to the requirements of building real-world enterprise systems, characteristics like scalability, maintainability, robustness and guaranteed future weigh more than a set of nice features.
    Tell that to log4j, struts, apache commons, or any other number of open source projects that aren't SUN standards but sure are INDUSTRY-ACCEPTED standards. (sorry for the caps instead of italics) Besides, last time I looked the marriage between JEE and Spring was going nicely. Sun standards usually lean toward ultimate flexibility which tends to make using them raw a pain in the ass - meaning many lines of code to to something simple. Spring adds a layered API on top of raw JEE which is aimed at developer productivity. To be very general, the top layer covers probably the 90% use scenario. You can then use the next layer down if you need more control. The other major benefit of Spring's design is that most of the time explicit Spring dependencies do not leak into your code. That is what is meant by lightweight containers.
    ...characteristics like scalability, maintainability, robustness...
    Seeing how Spring helps with these concerns for so called "real world enterprise applications" I'm not sure of your point. As for "guaranteed future", I think you are in the wrong industry. I wouldn't at all be surprised to see application containers start to deprecate their pre 3.0 EJB support or make that support available only with a pluggable module.
  35. Spring and XML[ Go to top ]

    One of those things that keep me off String is way to much XML plumbing. I don't like XML "declarative" style. XML is not an programming language and is not a data model. I think that Spring declarative development model is ok in its purpose, but formalizing it using XML in excess is not a strength point. Ok, Ok there are plug-ins for main IDEs, but I still prefer something like a(dd)notations ... I don't believe Spring will ever replace JEE because I think is built on top of JEE services (transactions, messaging etc.), so what Spring does is to create an easier model to assemble Java applications from JEE functionalities.
  36. Re: Spring and XML[ Go to top ]

    You are not obleiged to use XML http://blog.interface21.com/main/2006/11/28/a-java-configuration-option-for-spring/ Have fun :) -- Stéphane TRAUMAT http://www.scub.net/blogs/straumat/ +33 (0)5 45 373 373
  37. Re: Spring and XML[ Go to top ]

    One of those things that keep me off String is way to much XML plumbing. I don't like XML "declarative" style. XML is not an programming language and is not a data model.
    I think that Spring declarative development model is ok in its purpose, but formalizing it using XML in excess is not a strength point. Ok, Ok there are plug-ins for main IDEs, but I still prefer something like a(dd)notations ...
    I don't believe Spring will ever replace JEE because I think is built on top of JEE services (transactions, messaging etc.), so what Spring does is to create an easier model to assemble Java applications from JEE functionalities.
    First, you don't have to use XML as has been stated many, many times. Two, there are many of us who both and like and take advantage of the XML declarative style. I like it, use it, and am glad that it is but one option to configuration Spring. IMO, this particular reason is used by people who simply don't want to use Spring, and really can't produce a good reason. Say you don't like the developers, don't care for the philosophy, don't like the IOC approach, whatever, but stop using the XML configuration that represents one means of configuaration, and is enjoyed by others as an "excuse."
  38. Re: Spring and XML[ Go to top ]

    One of those things that keep me off String is way to much XML plumbing. I don't like XML "declarative" style. XML is not an programming language and is not a data model.
    I think that Spring declarative development model is ok in its purpose, but formalizing it using XML in excess is not a strength point. Ok, Ok there are plug-ins for main IDEs, but I still prefer something like a(dd)notations ...
    I don't believe Spring will ever replace JEE because I think is built on top of JEE services (transactions, messaging etc.), so what Spring does is to create an easier model to assemble Java applications from JEE functionalities.


    First, you don't have to use XML as has been stated many, many times. Two, there are many of us who both and like and take advantage of the XML declarative style.

    I like it, use it, and am glad that it is but one option to configuration Spring.

    IMO, this particular reason is used by people who simply don't want to use Spring, and really can't produce a good reason. Say you don't like the developers, don't care for the philosophy, don't like the IOC approach, whatever, but stop using the XML configuration that represents one means of configuaration, and is enjoyed by others as an "excuse."
    Exactly! I'm tired of people saying XML is the reason for not using Spring. Come on... find a different tune.
  39. Re: Spring and XML[ Go to top ]

    We had a major redesign for an Enterprise level consumer portal site for the past year. The Spring Framework really produced the miracle, IMO. We embrace 100% of Spring. Our POJO configuration fits nicely in all of the XML. With very careful component design, the Spring Context for a jar staying inside of the jar nicely. Searching for the bean definition is very simple using the regular IDE search. Due to our schedule and the Spring version, we didn't get a chance to move to the Spring Web Flow and Spring MVC, however, the Spring Struts integration still allow us to have a very nice decoupling from the WEB framework and the real POJO view factory. (We only have the FormBean dependency now...) And yet for the past few months, we have encountered a lot of requirements to swap out the MQ backend into web service based on the new SOA initiative. Not a problem, all we have to do is swapping out our command layer (which we have a standard interface) and not a single line change is needed in the other layer. We did even create a switch-able interface so both of the implementations can be easily switched and tested out. We are also fully prepared if the SOA team can not deliver their stuff on time. The switch can be triggered via a JSP (single JVM) or MBean (multiple JVM based on Spring MBean for WAS) or a timer (Spring Timer) using the same POJO implementation! Could this be done easily with the annotations? Maybe, but I will only look into that option seriously when we move out from WAS51, where it could be 3 years latter. I think what Spring (and XML configuration) has provided us something beyond Java and JEE. It makes our life so much easier when we need to deal with the "real-corporate" environment; where there is really no other "Standards" can help to make the other organization not to drop the ball. In a way, it's like a super tool that makes us the "Super Plumber", no matter what platform we are working on.
  40. Re: Spring and XML[ Go to top ]

    IMO, this particular reason is used by people who simply don't want to use Spring, and really can't produce a good reason. Say you don't like the developers, don't care for the philosophy, don't like the IOC approach, whatever, but stop using the XML configuration that represents one means of configuaration, and is enjoyed by others as an "excuse."
    Well said.
  41. Re: Spring and XML[ Go to top ]

    One of those things that keep me off String is way to much XML plumbing. I don't like XML "declarative" style. XML is not an programming language and is not a data model.
    Spring agrees with you. It isn't asking you to program in XML , just configure. As others have said Spring doesn't force you to use XML, that just happens to be the most adopted form of configuring. Other options: Using pure Java - though to me this is uglier than XML Using Groovy Builder - has potential Using I will say that developers learning Spring tend to over-configure their applications. I've seen Spring configurations where it appeared like the developers wanted to completely deprecate the Java "new" keyword. If you apply care you can configure a pretty large app with only one well laid-out configuration file.
    I don't believe Spring will ever replace JEE because I think is built on top of JEE services (transactions, messaging etc.), so what Spring does is to create an easier model to assemble Java applications from JEE functionalities.
    100% agree, however there are cases where it gives you an alternative to using the JEE equivalent, not just a layer on top of it. Also, Spring provides productivity where there is no solution at all in JEE.
  42. Yeah! Another JEE -vs- Spring discussion/argument. I find it so amusing that two terms that stand for a rather large collection of things can be dissed/defended so vigorously. But saying that Spring is the new Java EE is just silly. I, for one, only think of the IoC when I hear the word Spring - just like I only think of the Database when someone says Oracle - and think it adds a lot of value to my projects. However, I've never used the Spring web framework or several other parts of Spring and don't foresee doing so in the near future but I challenge someone to show me that it's become mainstream ? As for the argument about Spring and XML being an old one and only used by people who can't come up with a good argument, isn't this the same as the "Pro-Spring" camp always saying that EJB2 sucked so JEE must suck ? Who cares if EBJ3 improves the experience significantly or if the beauty of JEE is that you don't have to use everything in the stack and it allows you to use Spring or Hibernate or any home-grown alternative for whatever piece of your application that would be better served using these alternatives ? How long will it take for the general community to realize that there isn't one problem being solved and is certainly not one right solution to solve it.
  43. Yeah! Another JEE -vs- Spring discussion/argument.

    I find it so amusing that two terms that stand for a rather large collection of things can be dissed/defended so vigorously.

    But saying that Spring is the new Java EE is just silly. I, for one, only think of the IoC when I hear the word Spring - just like I only think of the Database when someone says Oracle - and think it adds a lot of value to my projects.

    However, I've never used the Spring web framework or several other parts of Spring and don't foresee doing so in the near future but I challenge someone to show me that it's become mainstream ?

    As for the argument about Spring and XML being an old one and only used by people who can't come up with a good argument, isn't this the same as the "Pro-Spring" camp always saying that EJB2 sucked so JEE must suck ? Who cares if EBJ3 improves the experience significantly or if the beauty of JEE is that you don't have to use everything in the stack and it allows you to use Spring or Hibernate or any home-grown alternative for whatever piece of your application that would be better served using these alternatives ?

    How long will it take for the general community to realize that there isn't one problem being solved and is certainly not one right solution to solve it.
    I don't think I've ever heard anyone who's used Spring say that JEE sucks. Spring uses JEE. I've heard people who use Spring say that Spring makes JEE easier to use and makes their applications cleaner, blah, blah, blah.. Again, if you don't want to use Spring, fine. Someday, I won't either, but XML is simply a lame reason, IMO.
  44. IMOH Spring will not replace JEE but rather complement it. In this debate several issues are mixed. JEE is often mistook for EJB. Spring is a foundation is often mistook for runtime operations environment. 1. Let's not confuse the whole JEE stack with EJB. Spring MVC builds on top of Servlets and JSPs, which are clearly JEE. It may be an alternative for JSF but it will not replace the JEE foundation. Spring POJO replacement for 'facade'/'services' will continue to rely on JTA which supplies 2PC integrtion between data-stores. JTA is clearly a JEE foundation that will continue to be relevant. Spring + JPA will continue to be a good alternative to EJBs (and here, Spring replaces JEE rather than complement it) Spring security will probably replace some JEE security facilities but will use JAAS as a foundation. This is one of the places in which JEE really sucks! 2. Let's not mix a foundation library with runtime environment: Spring is cool, but is it a foundation for development, not a runtime deployment and operations environment. Runtime deplyoment environment (such as commercial application servers) help operate clusters and deploy applications, manage cluster configuration, supply runtime information, alerting, problem detection, statistics and so on. Therefore, JEE servers will continue to be a good 'shell' for 'Spring+JEE' applications. Sure, more applications can anage with Tomcat+Spring, but many other will still want to enjoy an out-of-the-box JMS, Cluster domain management and other common BEA/Websphere/Oracle/JBoss features.
  45. One vendor?[ Go to top ]

    So Salil, et al, are happy with one vendor, Interface 21, being the new Java EE? One vendor defining/controlling everything in a proprietary manner outside of any standards bodies? How good would you feel if let's say Oracle bought Spring and controlled the "new Java EE"? Those of us who have this concern would feel much better if the technology and concepts I21 promotes would be brought to some standards body like JCP/EE6 and/or OSGi. Leaders of both specification efforts need to work hard to make this happen.
  46. I like Spring a lot but to say Spring is going to replace the entire Java EE stack is as uninformed as it gets. Sure, there are some less than stellar parts of JEE where Spring provides simpler and viable alternatives but for the rest of the specs Spring merely shields the application developers from the boilerplate plumbing. At no point does Spring try to provide alternatives to the servlet, JSP, JSF, JPA, JMS, JCA, JTA specifications but it does a great job of hiding the tedious plubming details one would otherwise have to deal with. Yes, there are some areas where Spring provides alternatives (Spring Web services instead of JAX-WX, SWF instead of using JSF's hideous navigation mechanism)which may prove to be better but it's not one or the other. Of course, whether we need a monolithic container to provide all these JEE spec implementations or we can pick and choose is another and perhaps, more important debate.
  47. The new bloatware[ Go to top ]

    "Perhaps most important is the fact that Interface21 plans to bundle this large collection of little parts that make up the Spring platform or portfolio, and make them available as a single download …or distro. Not just parts all slapped together, but tested and integrated, with the right versions, known to work with each other. I believe this will clinch it. Enterprise Java will mean Spring." I bet the sum of all of "small" parts will turn out to be just as big as a j2ee server. I love that our current Spring app ends up being a 35mb war file.
  48. I agree with all the recent posts. The whole purpose of spring was to remove Hard-wire dependencies from the code. That achieved, that simple concept has been leveraged to say that because one can plug in different implementations using Spring, those implementations are now a part of the Spring world. The only they are is - "Spring compliant". However, the way Spring framework has been evolving lately, its become as bloated and complex as a JEE container is and to me has whirled of the path it started of as. Simplicity and flexibility should have remained a hand-in-hand combination for Spring. In trying to do too much with the latter, Spring has added more complexity in terms of configuration details. I have no problem with Xml, but so far the tools for configuration have been pretty mediocre. Spring guys are in the same place that the Sun Java folks were a couple of years back. .NET has become an option for Java in certain situations because of ease and flexibility together. If Spring had stayed its course, it would have made its way into the core JEE spec for application servers and the two could have co-existed leveraging each other's benefits. Also, Spring's real benefits are seen more for infrastructure related module/library swap-outs than for most business application developers. Tools could have been developed to facilitate that at an application container level. Looks like Spring will end up making the same kind of mistakes as JEE, just on a different timeline. - Amit Karandikar
  49. I really like Spring and have used it on numerous projects. I kind of agree with Bill that the best features and innovations in the open source community should eventually move into the JAVA EE platform (this also includes some of the invocations coming from Seam :-)).
  50. common agree[ Go to top ]

    common agree
  51. I can't believe this discussion is still going on. What year is this, folks? So many stupid things being said that I really don't know where to start. In no particular order, some thoughts: 1. Spring is the new JEE is patently absurd. Spring may make certain aspects of JEE like EJBs less necessary but no less valid in given circumstances. Spring also works with JEE, making it easier to use if people so choose. Spring also rides on top of JEE and would be worthless without it. A lot of complexity here in their interrelationships that people want to simplify and turn into another Coke/Pepsi war. That's not the case here, so please move on. And I've been reacting like this in posts for several years now; you'd think people would finally get it. 2. Good to see the JBoss folks chime in with some more FUD about interface21. How would I like to see Interface21 be the only vendor for the new JEE? Well. considering the patent ridiculousness of that supposition (see #1 above), not very scared at all. Probably less scared than I'd feel about Jboss owning Hibernate, quite frankly. Roughly about as scared as I am about the Apache folks being the only vendor for all of the useful commons utility packages I use from time to time. The constant droning by JBoss wanks to drop Spring wouldn't be half as annoying if they weren't there waiting to offer you their own "solution" instead (and I'm not talking about their implementations of the JEE spec). Don't get me wrong, there are a lot of great JBoss products. But god, enough, people. Sell to us on merits, not used car tactics. 3. The idea of Spring not being ready for "enterprise" applications is ridiculous as well. Partly because it can be used in conjunction with many of the JEE technologies that are specifically designed to enable "enterprisiness". Partly because of the many examples of it doing just that in the wild (from experiences I've read about and based on my own). Partly because it's now used behind the scenes in BEA's JEE implementation, widely considered one of the most performant out there. Sounds like someone doesn't understand Spring and is trying the "can't run with the big dogs" argument. 4. Claims about Spring bloat are understandable but ill-informed. The project does include a lot of utilities that people may or may not use. But it is distributed such that you only need to use (and use JARs for) the parts that you need. I noticed that the recent version even breaks things down by persistence mechanism, so you only need to include the JAR for hibernate, for example, if you're not using TopLink or Ibatis. Honestly, take a look at the distribution and you'll see what I mean. 5. JEE is not just EJB. JEE is not just EJB. JEE is not just EJB. Repeat. It is also JDBC, JMS, JCA, JMX, servlets, JavaMail, JTA, etc, etc, etc. To say that Spring replaces this is, again, ridiculous. To say that Spring doesn't help use these technologies in certain cases is also ridiculous. That's all I can handle for now. I apologize in advance because this is easily the least reasonable and most anger filled post I've ever made on these boards in 6 years or so of posting. But I'm really getting tired of people screwing up discussions of the merits of a given technology with these ill-begotten pissing matches that make no actual sense and only serve to give insecure people some sad, illusory sense of belonging.
  52. Completely agree with above, quite a reasonable post actually. For most Spring web applications that have a single local data source (dare I say > 80% ?) a couple of things happen: ** the only Java EE "container" spec you need is the Servlet / WAR / web-app spec. Or in other words, you don't need EJB, JNDI etc. ** the application is 100% portable across all app servers starting from Jetty, Tomcat to JBoss, WebLogic, WebSphere etc. BTW, if you use Spring Security (Acegi) you can avoid using JAAS, again reinforcing the portability factor I'm sure a lot of you are seeing what I'm increasingly seeing in Spring projects, developers using Tomcat in dev mode even if in production the WAR file is deployed on something like WebLogic or WebSphere. Gets customers thinking all right. One hates to think how bad things would have been if the WAR spec was as nebulous as the EJB spec. And what if Spring and Hibernate had not come along. Anyway the point is - Spring does make a few critical Java EE standards (especially EJB) less relevant. Even now the misconception that J2EE == EJB is widely prevalent. It was not so long ago that the standard Java interview question was "life cycle of an EJB". *shudder* So it is not surprising that people jump to conclusions that Spring is the new Java EE. The other emotion you see is all the EJB container vendors getting upset :)
  53. Completely agree with above, quite a reasonable post actually.

    For most Spring web applications that have a single local data source (dare I say > 80% ?) a couple of things happen:

    ** the only Java EE "container" spec you need is the Servlet / WAR / web-app spec. Or in other words, you don't need EJB, JNDI etc.

    ** the application is 100% portable across all app servers starting from Jetty, Tomcat to JBoss, WebLogic, WebSphere etc. BTW, if you use Spring Security (Acegi) you can avoid using JAAS, again reinforcing the portability factor

    I'm sure a lot of you are seeing what I'm increasingly seeing in Spring projects, developers using Tomcat in dev mode even if in production the WAR file is deployed on something like WebLogic or WebSphere. Gets customers thinking all right.

    One hates to think how bad things would have been if the WAR spec was as nebulous as the EJB spec. And what if Spring and Hibernate had not come along.

    Anyway the point is - Spring does make a few critical Java EE standards (especially EJB) less relevant. Even now the misconception that J2EE == EJB is widely prevalent. It was not so long ago that the standard Java interview question was "life cycle of an EJB". *shudder*

    So it is not surprising that people jump to conclusions that Spring is the new Java EE.

    The other emotion you see is all the EJB container vendors getting upset :)
    I agree with most of what you said but JNDI is still usefull to most web application (defining a datasource in most case). I think JNDI is useful to reference external components but not internal components as with EJB 2.
  54. I agree with most of what you said but JNDI is still usefull to most web application (defining a datasource in most case). I think JNDI is useful to reference external components but not internal components as with EJB 2.
    I agree it is useful, but my point is it is not mandatory any more. I use commons-dbcp for a datasource and it works great.

  55. I agree with most of what you said but JNDI is still usefull to most web application (defining a datasource in most case). I think JNDI is useful to reference external components but not internal components as with EJB 2.

    I agree it is useful, but my point is it is not mandatory any more. I use commons-dbcp for a datasource and it works great.
    Yeah but I don't think you can use commons-dbcp to deploy in a 3 steps process fashion (functional testing, customer testing, production ) without having to change the ear. Personally, I use it only when I'm developping on my desktop and switch to JNDI when it's time to deploy (all is done automatically based on a system property).
  56. Yeah but I don't think you can use commons-dbcp to deploy in a 3 steps process fashion (functional testing, customer testing, production ) without having to change the ear. Personally, I use it only when I'm developping on my desktop and switch to JNDI when it's time to deploy (all is done automatically based on a system property).
    That is assuming if a) production *has* to be a JNDI data source and maybe that b) commons-dbcp is not production-strength Which I don't think is the case. Yes, some people recommend a JNDI datasource, my point is Spring gives you an alternative which I for one, am using. This simplifies end-user configuration at the time of deployment which is good when you are developing a product. You do have to manage the connection URL / username etc for your different environments but that is properties (file) management like you mentioned.
  57. ... and we digress - it is not Spring but commons-dbcp that provides an alternative to a JNDI datasource. Of course, Spring makes it so much easier to swap in our out as needed.
  58. That is assuming if a) production *has* to be a JNDI data source and maybe that b) commons-dbcp is not production-strength

    Which I don't think is the case.
    I never assumed that.
    Yes, some people recommend a JNDI datasource, my point is Spring gives you an alternative which I for one, am using. This simplifies end-user configuration at the time of deployment which is good when you are developing a product.

    You do have to manage the connection URL / username etc for your different environments but that is properties (file) management like you mentioned.
    Agreed about the choice argument. My point is that it isn't necessary to dump or reimplement all the good service an application server provide. You just have to be careful to not overuse them as it was often the case with JNDI (local EJB 2).
  59. I agree with Alexandre, JNDI is useful for interoperability. For example it is useful for several different Java applications to share a single JNDI-bound data source deployed on a production J2EE server. In this scenario you simply cannot make other applications to use Spring-managed datasource. Spring is a high-quality glue layer between fundamental J2EE technologies like JNDI, JTA, JavaMail, etc. Spring only replaces the weakest parts of J2EE like EJB and compliments others like Servlets(Spring provides a solid dispatching alternative for web.xml mappings and Spring MVC), JavaMail (Spring mail abstraction), JDBC and many more... Regards, Fyodor Kupolov Scriptella ETL - The only Apache licensed embeddable ETL tool with Spring support.
  60. God help us all...[ Go to top ]

    ...when the day comes that "XYZ is the new Spring" threads start showing up on TSS. And we know that day will come. :-)
  61. At its heart Spring is a glorified Factory pattern where you defined you object definitions in XML, and look them up using string names. Its got its advantages and disadvantages, but it is not a Servlet container, JDBC or JTA which are the heart of J2EE applications. regards Malcolm Edgar http://click.sourceforge.net
  62. At its heart Spring is a glorified Factory pattern where you defined you object definitions in XML,
    No longer true with Spring 2.1, which is annotation heavy.