Discussions

News: SpringSource acquires Covalent, gains Apache support network

  1. SpringSource has announced that they've acquired Covalent, which is becoming a division providing support for various Apache products, including Apache httpd. SpringSource is now going to be able to serve as a single source for Tomcat/httpd/Spring support, as well as adding Covalent's enhanced tooling. One research firm (BZ Research) says that Tomcat is in use at 64% of enterprises worldwide. Asked what drove the acquisition, Rod Johnson said that SpringSource was a product company, with the primary product being support subscriptions; it made sense to broaden their offerings to include the Apache project line through Covalent, as that's the dominant deployment platform. Apache httpd, for example, is commonly used even in cases where Tomcat is not, so SpringSource is able to support enterprises where WebSphere is being used with Spring behind httpd. The big changes for users here is that there's now a single source for support and indemnification around Apache and Spring. They also will offer enhanced tooling, management extensions, instrumentation tools, and support for Oracle RAC, an Oracle product that provides clustered databases. What do you think of the move?

    Threaded Messages (87)

  2. Seems like a great move by SpringSource. It doesn't make me think of Spring's agenda any differently as a developer and integrating with a support story just gives more continuity to the whole Spring development/support lifecycle. I'm sure SpringSource consultants will have an easier time filling out those system deployment plans by not forcing the systems people to take a leap of faith with Tomcat or ActiveMq. I have to think with the acquisition of BEA by Oracle, SpringSource must have worried about having a strong systems support marketing message going forward.
  3. I blogged about this also, explaining why we feel it's such a natural fit. Rod Johnson, CEO, SpringSource
  4. Since Spring is involved with OSGI and now Tomcat, can we expect Tomcat + OSGI?
  5. The question is: who will acquire SpringSource?
  6. The question is: who will acquire SpringSource?
    We believe that this acquisition helps us continue to grow a strong independent business. Being a one-stop shop for many customers helps us to control our destiny, rather than just be a juicy M&A opportunity.
  7. The question is: who will acquire SpringSource?
    I bet, negotiations are already underway and the Covalent acquisition should be seen in this context.
  8. Terracota[ Go to top ]

    I would love to see Terracotta part of their Portfolio too...!
  9. Mark
    Since Spring is involved with OSGI and now Tomcat, can we expect Tomcat + OSGI?
    Good question. The Spring Dynamic Modules for OSGi Service Platforms project went 1.0 final last week and combines the Spring component model with the OSGi modularization model. SpringSource is a leader in the server-side takeup of OSGi, which now has strong momentum. We're also actively involved in development of OSGi standards, and involved in the Equinox OSGi runtime at Eclipse. We think that OSGi is a big part of the future of enterprise Java, so it's a key direction for us. Rgds Rod
  10. Mark

    Since Spring is involved with OSGI and now Tomcat, can we expect Tomcat + OSGI?

    Good question. The Spring Dynamic Modules for OSGi Service Platforms project went 1.0 final last week and combines the Spring component model with the OSGi modularization model. SpringSource is a leader in the server-side takeup of OSGi, which now has strong momentum. We're also actively involved in development of OSGi standards, and involved in the Equinox OSGi runtime at Eclipse.

    We think that OSGi is a big part of the future of enterprise Java, so it's a key direction for us.

    Rgds
    Rod
    Is that a yes? ;) :)
  11. Since Spring is involved with OSGI and now Tomcat, can we expect Tomcat + OSGI? ...
    We think that OSGi is a big part of the future of enterprise Java, so it's a key direction for us.

    Rgds
    Rod
    Do we have to expect that OSGi standard will supplant a big part of the J2EE standard, and in practice, the next Java Application Servers will be OSGi based with or without an EJB plugin?
  12. We think that OSGi is a big part of the future of enterprise Java, so it's a key direction for us.


    Do we have to expect that OSGi standard will supplant a big part of the J2EE standard, and in practice, the next Java Application Servers will be OSGi based with or without an EJB plugin?
    These are orthogonal concepts. OSGi is about packaging, deployment, hot-pluggability, dependency, versioning, etc. EJB is a spec for writing a specific class of components. Application servers will likely use OSGi as a means to support modularization, but they will still likely support EJB and other JavaEE standards. Cross your fingers that JSR 277 keeps them orthogonal ;-) Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET


  13. These are orthogonal concepts. OSGi is about packaging, deployment, hot-pluggability, dependency, versioning, etc. EJB is a spec for writing a specific class of components.
    Yes, but OSGi is also about modularization that is included in concepts like j2ee modules and remote services. I'm not an expert of OSGi (I'm waiting for technology stableness and maturity) but I think that OSGi is a more complete spec that includes many J2EE functionalities.
  14. Application servers will likely use OSGi as a means to support modularization, but they will still likely support EJB and other JavaEE standards
    Eg. WebSphere 6.1 does this now. Kit
  15. Marc Fleury's thoughts[ Go to top ]

    Marc Fleury has some thoughts about this acquisition. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  16. Re: Marc Fleury's thoughts[ Go to top ]

    Interesting observations (Marc's comments). Firstly I should say congratulations Rod, Adrian, Juergen and the rest of the SpringSource team. In answer to some of the questions/statement (IMOHO of course), I can't see this being the strategy for SpringSource. It's does what BEA does for Oracle, it adds customers and better market coverage. The money is in commercial products, sometimes open but usually closed. I think the clever strategy is their announcement a few weeks ago with Spring Integration and perhaps Spring Batch and OSGi etc. Nice move guys, onwards and upwards, -John-
  17. Re: Marc Fleury's thoughts[ Go to top ]

    Frankly, I am just a programmer but to me this seems just a piece of shameless FUD.
  18. Re: Marc Fleury's thoughts[ Go to top ]

    Frankly, I am just a programmer but to me this seems just a piece of shameless FUD.
    FUD how? We've been funding a majority percentage of Tomcat development for years and years. Its very hard to monetize because Apache owns the brand. Most professional open sourcers know that the Apache model sucks for business. Why do you think Iona rebranded ServiceMix? Same reason. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  19. Re: Marc Fleury's thoughts[ Go to top ]

    Frankly, I am just a programmer but to me this seems just a piece of shameless FUD.


    FUD how?
    Just Marc trying to re-write history to seem a bit less irrelevant and you clutching on to his coat-tails as usual ;-) Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  20. Re: Marc Fleury's thoughts[ Go to top ]

    Marc Fleury has some thoughts about this acquisition.
    Woah ! Who's Marc Fleury ?
  21. Re: Marc Fleury's thoughts[ Go to top ]

    Marc Fleury has some thoughts about this acquisition.


    Woah ! Who's Marc Fleury ?
    I think he's known for tilting at windmills
  22. Congratulations to Rod and SpringSoruce teams. I wounder how you find time for coding, According to sources you are still active developer. Hope you won't give up developing Spring like Gavin King did with Hibernate. If your company now acquires good Hibernate replacement the world is yours. PS at least now we don't have to pay to 3 teams at once for support. Hiberate/Spring/Tomcat/GWT oops, anybody wants to acquire Google? ;-) Regards, Vitaliy S
  23. The SpringSource guys appear desperate. All the neverending noise how great the Spring framework is just reveals how scared SpringSource is about JBoss Seam. The situation is very clear. Keep in mind that there are venture capital funds invested in SpringSource (formerly Interface 21) with the hope of making money. So they are probably pressing SpringSource management (Rod Johnson) to get acquired as soon as possible. Of course, the SpringSource leaders want to get acquired too in order to be able to retire as open source millionaires (like Marc Fleury did). But who wanted to really buy SpringSource? The framework was innovative some years ago and brought us dependency injection and aspect oriented programming. But now it's a legacy software. If you compare JBoss Seam with Spring, Spring appears outdated. And I think the Spring leaders know this as well.
  24. The SpringSource guys appear desperate. ... If you compare JBoss Seam with Spring
    Is that you Marc?
  25. If you compare JBoss Seam with Spring, Spring appears outdated.
    Ok, I'm sold, show me the outdated thing.
  26. Look at the new features of Spring 2.5: the updated annotation-driven model for MVC, component scanning, jsr 250 annotations, @Autowired, integrated load-time weaving support and more; look at the new features going into Spring Web Flow 2.0 with the excellent JSF support and the enhancements to make creating accessible web applications easier; look at the growth of the Spring portfolio through projects such as Spring Batch and Spring Integration that make it much easier to incorporate different processing styles; heck, look at some of the not-so-new features that still lead the field such as the Spring AOP support. The Spring Portfolio is stronger and healthier than ever before, and far from being legacy it is leading the way in key industry trends such as the move towards OSGi. http://www.indeed.com/jobtrends?q=spring+java%2Cseam+java&l=
  27. Re: Job Trends[ Go to top ]

    depends on the perspective... http://www.indeed.com/jobtrends?q=spring+java%2Cseam+java&relative=1
  28. Re: Job Trends[ Go to top ]

    Ralf If you look at the relative graph (your link), you see the graph for Seam job reqs jump all over the place. That's because the absolute numbers for Seam are so low :-) If you like Seam and it makes you happy, that's great. But calling Spring "legacy," when it continues to innovate and evolve in so many areas, and implying that we're particularly worried about a specific challenger with a far more narrow scope and far smaller market share is just FUD. Some links showing the technology momentum (not just adoption momentum) behind Spring: Rgds Rod
  29. re: job trends (addendum)[ Go to top ]

    it doesn't make any sense at all to look only at the absolute numbers. Best proof: spring java vs struts java http://www.indeed.com/jobtrends?q=spring+java%2Cstruts+java Struts still leads by a wide margin. And as far as Struts is concerned, everyone agrees that it's legacy software.
  30. another interesting comparison[ Go to top ]

    spring java,j2ee java http://www.indeed.com/jobtrends?q=spring+java%2Cj2ee+java&l= In terms of absolute numbers, J2EE leads by a very wide margin (most recruiters still use the old 'J2EE' acronym instead of 'JEE' or 'EJB) So the comparison below is deliberately misleading. (speaks for itself and the credibility of the SpringSource guys!) Spring Overtakes EJB as a Skills Requirement (not true!) http://blog.springsource.com/main/2008/01/23/spring-overtakes-ejb-as-a-skills-requirement/
  31. Re: another interesting comparison[ Go to top ]

    Ralf, I'm really not very concerned about your view on my credibility--especially, as you've never posted on TSS except to promote Seam. However, I did write a book called J2EE without EJB a few years ago, explaining how J2EE is much more than EJB. Perhaps thousands of those companies recruiting agree :-) So I stand by my blog. R
  32. Re: another interesting comparison[ Go to top ]

    So what's misleading about trend comparisons between Spring and EJB that compare...Spring and EJB?
  33. Re: another interesting comparison[ Go to top ]

    So what's misleading about trend comparisons between Spring and EJB that compare...Spring and EJB?
    Hi Rod, let me clarify... When recruiters _nowadays_ state "J2EE" as job requirement, they typically mean "proficiency in latest Enterprise Java", so in most cases a requirement of "J2EE" doesn't mean "Enterprise Java WITHOUT EJB", but rather "Enterprise Java with latest EJB (EJB 3.0)". I'm aware that you are the author of the very good book "J2EE Development without EJB", Wrox 2004, so I know that it's possible to use many J2EE standards without EJB. Nevertheless, please note that recruiters are not technical people. For Enterprise Java they very often use the old term J2EE (rather than JEE or EJB) because it's the most common. Therefore, any job trend comparisons of EJB and Spring are misleading.
  34. Nevertheless, please note that recruiters are not technical people. For Enterprise Java they very often use the old term J2EE (rather than JEE or EJB) because it's the most common.
    Why was that renamed??? I don't get that. They are all crazy!
  35. Nevertheless, please note that recruiters are not technical people. For Enterprise Java they very often use the old term J2EE (rather than JEE or EJB) because it's the most common.

    Why was that renamed??? I don't get that. They are all crazy!
    the name was changed from J2EE to JEE (Java Enterprise Edition) when the JEE spec was was developed under JSR 244. The final release of that spec was made on May 11, 2006. It proves my point, though. Most people and in particular recruiters still use the old term 'J2EE' to refer to Enterprise Java.
  36. the name was changed from J2EE to JEE (Java Enterprise Edition) when the JEE spec was was developed under JSR 244. The final release of that spec was made on May 11, 2006.
    But why was it renamed??? EJB should have been renamed.
  37. Re: another interesting comparison[ Go to top ]

    Nevertheless, please note that recruiters are not technical people. For Enterprise Java they very often use the old term J2EE (rather than JEE or EJB) because it's the most common.

    Why was that renamed??? I don't get that. They are all crazy!
    I wish they had renamed it JSSE (java server side edition). But that was taken. People have a tendency to think that you have to use all or most of or some of JEE otherwise you are not doing enterprise applications.
  38. Re: another interesting comparison[ Go to top ]

    You don't need job stats to see the trend, EJBs were out of "fashion" over 5 years ago, most banks band their use as far back as 2002. The reason people still use J2EE is because it was the last version that anyone took seriously. Spring is by far the framework of choice in most Java development projects these days and it's going from strength to strength. There's not a single investment bank out there that isn't making serious use of Spring. Spring isn't perfect but Rod, Adrian, Juergen and team have done a far better job at defining a useful enterprise framework than Sun did with J2EE. -John-
  39. Re: another interesting comparison[ Go to top ]

    Spring isn't perfect but Rod, Adrian, Juergen and team have done a far better job at defining a useful enterprise framework than Sun did with J2EE.
    What a bunch of crap. J2EE != EJB. Last time I checked, Spring doesn't define JTA, JCA, JMS, Persistence, or even a servlet continaer API. All of which are a bit more useful than Spring. Lets show spring for what it is. I kiddy wrapper around *real* middleware that the big boys develop.
  40. Re: another interesting comparison[ Go to top ]

    Spring isn't perfect but Rod, Adrian, Juergen and team have done a far better job at defining a useful enterprise framework than Sun did with J2EE.


    What a bunch of crap. J2EE != EJB. Last time I checked, Spring doesn't define JTA, JCA, JMS, Persistence, or even a servlet continaer API. All of which are a bit more useful than Spring. Lets show spring for what it is. I kiddy wrapper around *real* middleware that the big boys develop.
    Both of you are correct. Sun did a great job defining all the plumbing APIs and Spring is great defining a framework. Personally I think plumbing is more important valuable.
  41. Re: another interesting comparison[ Go to top ]

    Lets show spring for what it is. I kiddy wrapper around *real* middleware that the big boys develop.
    oh I never realised. I will stop using Spring immediately The growth in the use of Spring in the City of London among all the major banks (US/European/Japanese) has been phenonmenal in the past 2/3 years. EJB was a catastrophe for enterprise Java and Rod Johnson (amongst others) deserve credit for providing disillusioned developers with re-newed hope and purpose (and of course a very useful framework). For me much alot of the success of Spring is down to the attitude shown by those closely associated with the project. They seem consistently interested only to providing the best technical solutions to problems, and show very little signs of inflated ego or the 'I know best, I don't care what anyone says' attitude. This I found and continue to find refreshing. If SpringSource continues to remain focused on providing us developers with good tools for solving *real* problems I have no doubt it will continue to grow and be a success.
  42. Re: another interesting comparison[ Go to top ]

    What a bunch of crap. J2EE != EJB. Last time I checked, Spring doesn't define JTA, JCA, JMS, Persistence, or even a servlet continaer API. All of which are a bit more useful than Spring. Lets show spring for what it is. I kiddy wrapper around *real* middleware that the big boys develop.
    O boy o boy, here comes the BIG BOY, Father of all Knowledge Bill Burke to say the definitive truth ! Beware !
  43. Re: another interesting comparison[ Go to top ]

    What a bunch of crap. J2EE != EJB. Last time I checked, Spring doesn't define JTA, JCA, JMS, Persistence, or even a servlet continaer API. All of which are a bit more useful than Spring. Lets show spring for what it is. I kiddy wrapper around *real* middleware that the big boys develop.
    Here we go, the Burke lives up to his name. OK, I agree J2EE != EJB, EJB was the really crappy bit and there were some excellent APIs in J2EE but they were there before J2EE. JCA is a design fix and has little use outside of J2EE (unless of course you mean the Cryptography API but I doubt it), JTA wasn't from Sun if I remember correctly and JMS was from a number of vendors. I stand by my imperfectly worded statement, J2EE has some good APIs but as an enterprise tool box it is difficult to make work without something like Spring. Spring did a better job at truly enterprise frameworks than Sun.
  44. Re: another interesting comparison[ Go to top ]

    What a bunch of crap. J2EE != EJB. Last time I checked, Spring doesn't define JTA, JCA, JMS, Persistence, or even a servlet continaer API. All of which are a bit more useful than Spring. Lets show spring for what it is. I kiddy wrapper around *real* middleware that the big boys develop.


    Here we go, the Burke lives up to his name.
    Don't be too harsh; it can't be easy living with an inferiority complex like that. (And comments like these are just going to make it worse.) Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++
  45. Re: another interesting comparison[ Go to top ]

    another word of J2EE vs. Spring comparison: http://www.indeed.com/jobtrends?q=spring+java%2Cj2ee+java&l= In absolute terms, "J2EE Java" (with J2EE being the old term for Enterprise Java) yields more than 4 times the jobs offers "Spring Java" does! So what does this tell us? It does tell us that for 75% of all J2EE job offers Spring is NOT listed as a requirement. Therefore, I'd hardly go as far and publicly claim that Spring has overtaken EJB technology for the business layer. Sorry for being so harsh, but I was not the one who repeatedly bashed the new EJB 3.0 technology just to promote my own business.
  46. Re: another TSS rant[ Go to top ]

    but I was not the one who ...
    No, but you're the one who repeatedly plugs one companies technologies and disses another companies technologies. People may question your motivations ... particularly as nobody has heard of you before today, your employer, your connections, etc.
  47. Re: another TSS rant[ Go to top ]

    but I was not the one who ...

    No, but you're the one who repeatedly plugs one companies technologies and disses another companies technologies.
    repeatedly? Come on, I registered today!
    People may question your motivations ...
    yes, and this would be absolutely legitimate. So what are my motivations and connections? Full disclosure just for the record: I'm neither affiliated with any EJB-vendor nor with any company which competes against the Java platform (such as Microsoft or Adobe). In my view the biggest and most serious competitor to the Java platform is Microsoft. Hence, we as Java developers should stick together. The new JEE platform, INCLUDING the latest EJB 3.0 standard is MUCH better than certain people want us make believe. We do not need traitor companies within our own ranks that repeatedly talk this technology down just in order to establish their own standards. This is not doing the Java camp any favor at all.
  48. Re: another TSS rant[ Go to top ]

    We do not need traitor companies within our own ranks that repeatedly talk this technology down just in order to establish their own standards. This is not doing the Java camp any favor at all.
    Ralf, you totally lack context and a sense of history in your rant. If you roll back say four+ years ago when Sun/IBM/BEA/JBoss were killing their clients by foisting EJB as THE blessed solution (kinda like JSF today), and Microsoft was a viable alternative with .Net, Springframework was just an idea in a book. As I remember, the idea grew into a framework, and the framework got used because it was a great alternative to the blessed JEE technologies. The message has not changed in all these years. So to say it competes against Seam or EJB, well DUH! The fact that JBoss uses Tomcat only makes SpringSource stronger as JBoss customers realize they don't need the EJB container. You would think RedHat PR would learn to put a muzzle on JBoss FUD.
  49. Re: another TSS rant[ Go to top ]

    Ralf, you totally lack context and a sense of history in your rant. If you roll back say four+ years ago when Sun/IBM/BEA/JBoss were killing their clients by foisting EJB as THE blessed solution (kinda like JSF today), and Microsoft was a viable alternative with .Net, Springframework was just an idea in a book. As I remember, the idea grew into a framework, and the framework got used because it was a great alternative to the blessed JEE technologies. The message has not changed in all these years. So to say it competes against Seam or EJB, well DUH!
    I do not have the time right now to post a lengthy response: But the facts remain: When comparing job tends, note that it was Rod Johnson who publicly started this and in a misleading way to promote Spring, 'J2EE Java' yields 0.8 while 'Spring Java' yields around 0.2 (percentage of matching job posting). This tells us two things: First, the Spring framework got adopted in the market, otherwise the percentage of job postings with Spring as requirement would be lower (Spring it is a well-done and innovative framework). Second, the number of job postings with J2EE as a requirement exceeds the number of job postings with Spring as a requirement by the factor 4!!! Based on such a simple comparison it remains unclear what technology is used for the transactional business layer if the Spring framework is not used. In many cases probably EJB which could mean both the old EJB 2.x (which is outdated now) or the newer EJB 3.0 (many recruiters still use the term J2EE, even when they actually want to refer to JEE 5). If interest in EJB was really so low as Rod Johnson wanted us make believe ( http://blog.springsource.com/main/2008/01/23/spring-overtakes-ejb-as-a-skills-requirement/ ), we should expect a much higher percentage of job postings where Spring is listed as required skill compared with the result for j2ee and definitely not the result that the number of job offers with J2EE exceeds the number of job offers with Spring as requirement by the number of 4!
  50. Re: another TSS rant[ Go to top ]

    You are telling me that when you design a system, you check job postings first. There aren't a lot of ways for a recruiter to concisely ask someone if they have Enterprise Java skills other than to say JEE. It's in the ballpark to get you a phone screen. When I interview someone I ask a candidate about alternatives. This brings out the better developers. Those that mention EJB2/3 tend to be uninspired followers. As for Rod. I have his books, seen his posts, and I use his framework. It seems to take a lot to get his blood up as he stays on message promoting as he goes. Been this ways for years. He's a clear asset in the valuation of SpringSource I bet. A clean vision with consistently innovative, well documented product. He may interpret stats to favor his product but we all know better to trust him or you on the subject.
  51. Re: another TSS rant[ Go to top ]

    In my view the biggest and most serious competitor to the Java platform is Microsoft.
    Hmmmm. Sounds like Rolf. For those of you who remember. The rest of the post doesn't however.
    We do not need traitor companies within our own ranks that repeatedly talk this technology down just in order to establish their own standards. This is not doing the Java camp any favor at all.
    Strong words. Rolf would say he is just pointing out that the emperor has not clothes. That and some of the wall literary quote.
  52. Re: another TSS rant[ Go to top ]

    Hmmmm. Sounds like Rolf. For those of you who remember.
    The odd nut-case like Rolf and Ralf could do wonders for TSS reading figures :-) -John-
  53. Therefore, I'd hardly go as far and publicly claim that Spring has overtaken EJB technology for the business layer.
    So what? I don't know a better name for Spring but Spring.
  54. Re: another interesting comparison[ Go to top ]

    Sorry for being so harsh, but I was not the one who repeatedly bashed the new EJB 3.0 technology just to promote my own business.
    These personal attacks get tedious Facts are facts and your quibbles regarding naming are unconvincing. I compared Spring with EJB, not J(2)EE, and the results are clear. My views on EJB have been a matter of public record for several years. I believe that EJB 3.0 is an unimpressive technology, and expressed that (and argued why) before SpringSource (Interface21) was founded. I founded the company as a result of my strong views on where the technology was going and needed to go; my corporate affiliation does not dictate my views. I have always distinguished EJB from J(2)EE, including in the blog in question--in fact I'm a member of the Java EE 6 expert group. By contrast, as another poster pointed out, you are unknown to Google and have never posted here except to promote Seam--always a concern on TSS. Rgds Rod CEO, SpringSource Founder, Spring Framework
  55. it is leading the way in key industry trends such as the move towards OSGi.
    What are you leading here? OSGi is more then simple 'Component model', so don't flatter yourself too much. It's the likes of IBM, Prosyst and Jayway that are leading the OSGi way. You are again just a fancy wrapper around existing stuff, like most of Spring ...
  56. Ales I believe you forgot the disclaimer: I am an employee of JBoss (Red Hat), so expect FUD about Spring, SpringSource and all to do with it. Honestly, don't you guys have day jobs? Or are you really really worried about something? Two hostile JBoss blogs with 24 hours of our acquisition of Covalent have been the only negative press thus far of a huge amount of coverage. Maybe that indicates how far you are out of step with the wider world. We are playing an active role (leading in some areas) in the OSGi Alliance. Adrian Colyer is leading one of the OSGi specifications. The innovation in Spring OSGi has been praised by many third parties, including key OSGi experts such as Peter Kriens, and is being adopted by BEA, Oracle and many other companies. Rgds Rod
  57. Ales

    I believe you forgot the disclaimer: I am an employee of JBoss (Red Hat), so expect FUD about Spring, SpringSource and all to do with it. Honestly, don't you guys have day jobs? Or are you really really worried about something? Two hostile JBoss blogs with 24 hours of our acquisition of Covalent have been the only negative press thus far of a huge amount of coverage. Maybe that indicates how far you are out of step with the wider world.

    I don't think it matters here who I work for. I simply stated a simple OSGi fact, which you again tried to exploit with over exaggerating your involvement in that space. You've already put enough bullshit about JEE, so, please restrain yourself from doing the same with OSGi. It's not fair to the hard working people that actually make OSGi go around. It's not all about the fancy wrappers, even though you might think that's the point of the whole development ... And it's ('your') OSGi we're talking about, so please, don't push that Covalent crap here, since it has nothing to do with this thread. Trying to turn away the attention won't make the OSGi fact go away. And you're pathetic with marking everything we say as FUD, and preaching us about the day job. Take a look in the mirror, and see what've you done the last few blogs, TSS replys, ...
    We are playing an active role (leading in some areas) in the OSGi Alliance. Adrian Colyer is leading one of the OSGi specifications. The innovation in Spring OSGi has been praised by many third parties, including key OSGi experts such as Peter Kriens, and is being adopted by BEA, Oracle and many other companies.
    Why are you explaining me this? Do your homework before you post. Or better, ask Adrian. But let's make this first correction - you're not leading areas, you're leading a single area, the 'Component model'. I actually like what you're doing there, although it's a lot similar to DSS, meaning it's not really an innovation. But I give you, Adrian exactly, credit for spotting quirks around the previous spec. But that's why there is EEG.
  58. please, don't push that Covalent crap here,
    So we have a story about SpringSource acquiring Covalent and we have some Ralf character who mysteriously appears out of the ether with a deep-rooted personality complex about Spring wanting to change the topic. And then when people keep smacking him down we have JBoss employees full of rhetoric (as ever) wanting to change the topic, and deny the existence of the original story. Where's Rikard when we need him to psychoanalyse this freak show. Keep it going JBoss its making my day so much more fun. Don't let rational thought get in the way ... :-)
  59. Spring OSGi[ Go to top ]

    Ales You also conveniently forgot to mention JBoss's debt to Spring OSGi. Let me quote from a post you made in your JBoss forums back in December 2006:
    I went over the r4 spec and Spring's OSGi integration - and this is probably really the same thing we want to have. What's really important is that Spring's OSGi spec (http://www.springframework.org/osgi/specification ) was influenced a lot by the same people (core OSGi EG members) that we are also involved with - so doing something totally different doesn't make sense. Ok, the two impls would look a lot the same (if somebody has a problem with this, let me know), but I don't think we are here to reinvent the wheel. We are basically trying to put a good spec onto MC's behaviour... Our OSGi project would be (similar to Spring's) divided into different modules...
    Frankly, the incessant JBoss hostility toward Spring is intellectually dishonest and can presumably only be motivated by competitive fear. Given the number of your accounts (and reference customers) that are essentially using Spring and Tomcat (like the French Tax Office), I can understand why. Rgds Rod
  60. Re: Spring OSGi[ Go to top ]

    Ales

    You also conveniently forgot to mention JBoss's debt to Spring OSGi. Let me quote from a post you made in your JBoss forums back in December 2006.
    What debt? If by debt you mean my initial experimenting on top of your work, I'm more than welcome to buy Adrian and Costin a beer. Like I said in my previous post, I like what you're doing. And it's a (nice) surprise that you're finally trying to put some spec on top of your work. So at the end it won't be re-inventing the wheel, but it will be implementing the spec. But once again, let's not blow up this piece of work like it's the core OSGi stuff. It's a mere DSS2 with sugar on top. And DSS1 didn't get much attention ...
    Frankly, the incessant JBoss hostility toward Spring is intellectually dishonest and can presumably only be motivated by competitive fear. Given the number of your accounts (and reference customers) that are essentially using Spring and Tomcat (like the French Tax Office), I can understand why.
    Here you go again. Can't you ever stick to the topic?
  61. Re: Looks like a deal out of desparation[ Go to top ]

    If you compare JBoss Seam with Spring, Spring appears outdated. And I think the Spring leaders know this as well. .
    Compare what to what? They both have an 's' in them? Let's compare golf balls and sushi while we are at it.
  62. Spring is an enormous contributor to EJB improvements, but on the other hand it's the main factor for J2EE disruption. It's very well accepted by many developers, however will probably never be adopted as standard.
  63. my bias 2 bits[ Go to top ]

    Since the flame war is going well, here's my bias 2 bits. I don't work for either spring or jboss, so I'm "mostly" impartial. Having used EJB1, EJB2 and Spring, my personal take is Spring isn't lighter, or better. It's different, but being different doesn't automatically mean better. Spring does a few things nicely, but I could name a few things where Spring sucks. I've had to work around plenty of things the last year in spring, so to claim it's whole sale better is a flat out lie. I'm sure there are plenty of people that will love spring. Spring did make contributions to J2EE world, but I am so tired of people claiming Spring is better without seeing the limitations and weaknesses. EJB is hard to use and many people, including myself have misused it. That's not EJB's fault that I made a mistake and had to learn the hard way. All the people bitching and moaning about EJB shouldn't blame the technology. Blame the idiot sales people who over sold EJB. The same can be said of Spring. When used appropriately, Spring can make life easier, but it's not a magic wand. let the flame continue. peter
  64. Re: my bias 2 bits[ Go to top ]

    Since the flame war is going well, here's my bias 2 bits. I don't work for either spring or jboss, so I'm "mostly" impartial. Having used EJB1, EJB2 and Spring, my personal take is Spring isn't lighter, or better. It's different, but being different doesn't automatically mean better.

    Spring does a few things nicely, but I could name a few things where Spring sucks. I've had to work around plenty of things the last year in spring, so to claim it's whole sale better is a flat out lie.

    I'm sure there are plenty of people that will love spring. Spring did make contributions to J2EE world, but I am so tired of people claiming Spring is better without seeing the limitations and weaknesses. EJB is hard to use and many people, including myself have misused it. That's not EJB's fault that I made a mistake and had to learn the hard way. All the people bitching and moaning about EJB shouldn't blame the technology. Blame the idiot sales people who over sold EJB.

    The same can be said of Spring. When used appropriately, Spring can make life easier, but it's not a magic wand. let the flame continue.

    peter
    What is tiring is people who proclaim that others "can't see." Why is it that the people who seem hate Spring the most(or any technology) always claim that the people who use it just don't understand, like somehow they are privy to some secret that the rest of the world just doesn't get. Show ONE post where anyone besides detractors said "Spring is a silver bullet," magic wand, or implies that it solves every problem. People, I think, found that Spring worked well, better in fact than pure EJBs. Lots of people, which translated to lots of posts, as opposed to lots of dummies deluding themselves.
  65. clarification[ Go to top ]

    Since the flame war is going well, here's my bias 2 bits. I don't work for either spring or jboss, so I'm "mostly" impartial. Having used EJB1, EJB2 and Spring, my personal take is Spring isn't lighter, or better. It's different, but being different doesn't automatically mean better.

    Spring does a few things nicely, but I could name a few things where Spring sucks. I've had to work around plenty of things the last year in spring, so to claim it's whole sale better is a flat out lie.

    I'm sure there are plenty of people that will love spring. Spring did make contributions to J2EE world, but I am so tired of people claiming Spring is better without seeing the limitations and weaknesses. EJB is hard to use and many people, including myself have misused it. That's not EJB's fault that I made a mistake and had to learn the hard way. All the people bitching and moaning about EJB shouldn't blame the technology. Blame the idiot sales people who over sold EJB.

    The same can be said of Spring. When used appropriately, Spring can make life easier, but it's not a magic wand. let the flame continue.

    peter


    What is tiring is people who proclaim that others "can't see." Why is it that the people who seem hate Spring the most(or any technology) always claim that the people who use it just don't understand, like somehow they are privy to some secret that the rest of the world just doesn't get.

    Show ONE post where anyone besides detractors said "Spring is a silver bullet," magic wand, or implies that it solves every problem.

    People, I think, found that Spring worked well, better in fact than pure EJBs. Lots of people, which translated to lots of posts, as opposed to lots of dummies deluding themselves.
    I didn't mean to claim people "can't see". What I find unhelpful is someone claiming spring is better, if they haven't hit the limits of spring and haven't seen where it is fails. I'll be blunt. EJB is no picnic either. Each technology has merits and I've had to work around both technologies. That doesn't make either one good, bad, better or worse. If spring meets the projects needs then great. If ejb meets the needs then great. My bias take is Spring works well in the hands of someone who understands Spring. EJB works well in the hands of someone who understands EJB. I argue that Spring isn't better than pure EJBs. I haven't worked on simple web applications in a long time, so I fully accept that many people find Spring better and feel more comfortable with it. I've mainly worked on complex applications where all transactions have sub transactions or complementry transactions. In those cases, I don't believe the semantics defined in Spring's transaction API make complex transctions easier. then again, complex transactions are complex, so there's no getting around that. peter
  66. Re: clarification[ Go to top ]

    At the risk of turning over this rock :-), here was something that attracted me from EJB to Spring. Scalablity, not performance, but architecturally. EJBs are not good for smaller projects. What I found for Spring-based stuff, at least mine, was that I was able to create a "framework" as in, a combination of OSS, in-house code, and convention, that could scale to a project as small as two page web. Would you use EJBs for such a small project? Probably not. But for us, we had the same architecture, code code, configuration, security, caching, etc for your smallest, projects to our largest. In fact, I would start new people off by having them make some changes to a 3 page application. If you understood how this worked, you knew the larger ones. Even small apps benefited from declarative transactions, but who would want to run such a small thing in JBoss or Oracle9iAS. EJBs just didn't deliver the portability they promised. Trying writing an app back in the day on JRun, then deploy that EJB-based app on Oracle9iAS. You were nailed by the fact that JRun didn't quite follow the spec, and Oracle9iAS was more rigid(but still didn't follow the servlet spec, precisely). Spring put the whole thing in Tomcat. Or WebSphere. We had projects that ran across Tomcat, Websphere, JRun, and Oracle9iAS. Try deploying that EJB in all of the above. Also, I don't think it is an issue of say Spring's transactions making them easier. Instead, how about being able to more easily bring that too even smaller apps. Or do this *outside* of an Appserver. Or, bring consistency to how we accessed resources? And let's not forget about being able to forgo extending the variety of EJB interfaces of days pass - EJBLocal anyone? In EJBs, you had this whether you wanted them or not. Oh, and multi-threading. If you wanted to spawn a thread, EJBs were a problem, right? I think that fact that EJB3 borrowed from Spring is validation. And those EJB callbacks..sheesh. I could go on and on :-)
  67. Re: clarification[ Go to top ]

    I agree there's lots of challenging and difficult things with EJB. I remember using EJB and JMS before message driven beans. Just my opinion, but chances are Spring will be easier for a new developer to pick up. Having said that, just because it is easier for a new developer to pick up doesn't mean it's better. It's better for a new developer joining a team that's already using Spring. Getting EJB's to run across multiple ejb containers is feasible, but it's not necessarily easy. In those cases i would agree it is probably going to be easier to go a non-ejb route. Whether that route is Spring depends on the project. Over the last few years, many people have said Spring is better than EJB on TSS. It's just my opinion, but Spring isn't inherently better. It's only better if the developers and project match the sweet spot. I suspect for lots of projects, Spring hits the sweet spot. What is sad is when clueless Executives make declarations like use EJB, use Spring, use BRE without the slightest clue. Unfortunately, that's how it is at large companies and will always be that way. Spring DI does make life easier for many suitations, but sometimes it doesn't quit fit when you end up having to use dependency pull. At that point, I have to ask myself, is DI doing me any good if all my services need to do a dependency pull? I'm sure plenty of people have come across that issue. peter
  68. Re: clarification[ Go to top ]

    What is sad is when clueless Executives make declarations like use EJB, use Spring, use BRE without the slightest clue.
    And the biggest con ever is POJO.
  69. Re: clarification[ Go to top ]

    Spring DI does make life easier for many suitations, but sometimes it doesn't quit fit when you end up having to use dependency pull. At that point, I have to ask myself, is DI doing me any good if all my services need to do a dependency pull?
    DI with Spring is not purely static. Spring method injection (available since 1.1) can help in such cases. (Search for "method injection" here). AFAIK it's a unique feature. You can also easily get hold of the container reference (for name or type based lookup) by implementing a callback like ApplicationContext Aware or like this: @Autowired private ApplicationContext ac; Spring can also easily inject a proxy whose target can transparently change over time--for example, backed by a custom scope. Alternatively, if you're willing to compile with AspectJ or use AspectJ load time weaving you could use @Configurable and have Spring injection on objects constructed using the new operator. Spring goes a lot farther in these scenarios than other DI solutions. But of course no technology, DI or anything else, is a perfect fit in all scenarios. Rgds Rod
  70. Re: clarification[ Go to top ]

    Annotations are good if someone isn't using Websphere or jdk1.4.2. There's a huge population out there stuck with jdk1.4.2, so having circular dependencies across services may not be the best fit for DI. In cases where services have a clear and clean delineation, DI is very handy. One thing I haven't seen many people point out is that using DI and proxies make it harder to debug. Recently I had to debug some complex services, but it was rather painful because of all the proxies. In the situation where DI isn't used, debugging and stepping through the code on the server side is simpler since there's isn't any proxies. again, just my bias opinion. peter
  71. Re: clarification[ Go to top ]

    Note that Spring's DI capabilities do not imply the use of proxies - not at all. Technically, Spring's core container doesn't even know what a proxy is. If you encounter proxies in debugging, then you happen to be using AOP functionality - for some interceptors or interceptor-based services that you explicitly configured. So in that respect, you got what you asked for... That would be the same with any other solution that provides similar services, e.g. EJB 3 Session Beans which inherently have to be fronted with a proxy as well - even more so there because of the baked-in instance pooling. BTW, Spring allows you to choose AspectJ weaving instead of proxies: e.g. applying Spring's @Transactional annotation through ... modifying the byte code instead of using proxies. Spring 2.5 even explicitly supports load-time weaving for such aspects, at least in environments that are capable of class instrumentation: Check out the configuration facility. As for WebSphere and JDK 1.4.2: Spring 2.5 is still compatible with JDK 1.4.2 and WAS 5.1/6.0, providing a wealth of functionality on that platform as well (except for annotation support, of course). Spring is quite unique in its ongoing support there, since almost all of today's frameworks sacrifice JDK 1.4 support... whereas Spring provides JDK 1.4 support alongside in-depth JDK 1.5/1.6 support in the up-to-date Spring 2.5 generation. Juergen
  72. Re: clarification[ Go to top ]

    Note that Spring's DI capabilities do not imply the use of proxies - not at all. Technically, Spring's core container doesn't even know what a proxy is.

    If you encounter proxies in debugging, then you happen to be using AOP functionality - for some interceptors or interceptor-based services that you explicitly configured. So in that respect, you got what you asked for... That would be the same with any other solution that provides similar services, e.g. EJB 3 Session Beans which inherently have to be fronted with a proxy as well - even more so there because of the baked-in instance pooling.

    BTW, Spring allows you to choose AspectJ weaving instead of proxies: e.g. applying Spring's @Transactional annotation through ... modifying the byte code instead of using proxies. Spring 2.5 even explicitly supports load-time weaving for such aspects, at least in environments that are capable of class instrumentation: Check out the configuration facility.

    As for WebSphere and JDK 1.4.2: Spring 2.5 is still compatible with JDK 1.4.2 and WAS 5.1/6.0, providing a wealth of functionality on that platform as well (except for annotation support, of course). Spring is quite unique in its ongoing support there, since almost all of today's frameworks sacrifice JDK 1.4 support... whereas Spring provides JDK 1.4 support alongside in-depth JDK 1.5/1.6 support in the up-to-date Spring 2.5 generation.

    Juergen
    you're absolutely correct DI doesn't require proxies. Which is why I said DI is quite powerful and useful. Adding DI with proxies like autoproxy in spring 1.x can make things much more difficult to debug. Especially if there's several autoproxies defined for the services. My point is that it isn't all roses and peaches as some people make Spring out to be. I won't bother pointing all the annoying things about EJB, since most people with 5 or more years of experience have seen it first hand. Having choices is good. My bias opinion is that all this ejb bashing is pointless and totally counter productive. It has merits, even if it has a steep learning curve. I think it's pretty safe to say the IT world owes a huge thanks to Ramnivas Laddad for making AOP popular and helping to plant the seeds of DI. There are things in spring I like and there are things in spring I dislike. At the end of the day, I have to use the tools my customers have chosen. Given a choice, I would by pass spring and ejb and go with just tomcat and add things as needed. The only real advantage I see with Spring over IBM or BEA is that I can see the code. peter
  73. Re: clarification[ Go to top ]

    Annotations are good if someone isn't using Websphere or jdk1.4.2. There's a huge population out there stuck with jdk1.4.2, so having circular dependencies across services may not be the best fit for DI.

    In cases where services have a clear and clean delineation, DI is very handy. One thing I haven't seen many people point out is that using DI and proxies make it harder to debug. Recently I had to debug some complex services, but it was rather painful because of all the proxies. In the situation where DI isn't used, debugging and stepping through the code on the server side is simpler since there's isn't any proxies.

    again, just my bias opinion.

    peter
    I believe that the advantages offered by DI and AOP outweight the "harder" debugging. OOP is harder to debug than procedural, but the advantages, again, outweight this issue. In my cases, I made sure 1)People were educated on how to tell whether or not a proxy was in place 2)Set things up that seemed to make it easy to know where they were. I used AOP to provide security, enhanced exception handling(mapping, retries), caching, and profiling and over the course of years, I had no problems with new team members debugging the system.
  74. Re: clarification[ Go to top ]

    Annotations are good if someone isn't using Websphere or jdk1.4.2.
    You can accomplish what I showed without annotations using the ApplicationContextAware interface. It's just slightly more verbose, but amounts to the same thing. Spring 2.5 still supports JDK 1.4 (although obviously not all new features are available) and yes, there is a significant population still on 1.4 with WebSphere.
  75. Re: clarification[ Go to top ]

    Annotations are good if someone isn't using Websphere or jdk1.4.2.

    You can accomplish what I showed without annotations using the ApplicationContextAware interface. It's just slightly more verbose, but amounts to the same thing. Spring 2.5 still supports JDK 1.4 (although obviously not all new features are available) and yes, there is a significant population still on 1.4 with WebSphere.
    thanks for the info. Is that feature available in spring 1.x?
  76. Re: clarification[ Go to top ]

    Peter, Yes, the ApplicationContextAware interface is available on Spring 1.x. Here's the JavaDoc Mark
  77. Re: clarification[ Go to top ]

    Peter,

    Yes, the ApplicationContextAware interface is available on Spring 1.x. Here's the JavaDoc

    Mark
    thanks for the link. I wasn't aware that feature is there in 1.x. peter
  78. Re: clarification[ Go to top ]

    Thanks for the info. Is that feature available in spring 1.x?
    Are you referring to ApplicationContextAware? That has been available since Spring 0.9, actually... For the nicest possible configuration experience, I'd strongly recommend an upgrade to Spring 2.5, though - or at least to Spring 2.0.8. No matter whether you're running on JDK 1.4 or 1.5, this will definitely pay off. Such a Spring upgrade should be smooth, with no need to upgrade the application server platform as well... Juergen
  79. Re: clarification[ Go to top ]

    Thanks for the info. Is that feature available in spring 1.x?


    Are you referring to ApplicationContextAware? That has been available since Spring 0.9, actually...

    For the nicest possible configuration experience, I'd strongly recommend an upgrade to Spring 2.5, though - or at least to Spring 2.0.8. No matter whether you're running on JDK 1.4 or 1.5, this will definitely pay off. Such a Spring upgrade should be smooth, with no need to upgrade the application server platform as well...

    Juergen
    upgrading may be an option for some people, but many places it's not. I'm sure others have been in similar situations, where some software cop watches everything and says what is allowed or not.
  80. Re: clarification[ Go to top ]

    Thanks for the info. Is that feature available in spring 1.x?
    The Method Injection feature I mentioned as a "pull" alternative has been available since 1.l also. Rgds Rod
  81. Re: clarification[ Go to top ]

    For the nicest possible configuration experience, I'd strongly recommend an upgrade to Spring 2.5, though - or at least to Spring 2.0.8. No matter whether you're running on JDK 1.4 or 1.5, this will definitely pay off. Such a Spring upgrade should be smooth, with no need to upgrade the application server platform as well...
    For me the migration to 2.5 was not so smooth (see also): For the hibenate current_session_context_class you have to use a spring specific class (just omit the property in the hibernate config). Unfortunately I have to integrate a legacy application, that uses hibernate but doesn't know anything about the spring stuff. In the previous versions I used thread/jta for the session context and everything worked fine. Now with the SpringSessionContext the legacy application doesn't get a new transaction, if none was already started (SessionFactory#getCurrentSession()). Do you have a work around for me?
  82. Re: clarification[ Go to top ]

    I'm not sure I understand correctly: Legacy code that doesn't know about Spring at all shouldn't need to participate in Spring-managed transactions either, so you're free to specify any Hibernate CurrentSessionContext class there. If, on the other hand, you do want that code to participate in Spring-managed transactions (e.g. using Spring's HibernateTransactionManager), then you need to use the SpringSessionContext class - since it doesn't make sense to use any other Session management strategy then. This choice was the same with Spring 2.0, actually. The only difference being that Spring 2.0 always used its own Session management unless you explicitly switched it off, no matter what "current_session_context_class" you specified in your Hibernate configuration. Spring 2.5 honors that Hibernate setting now, not overriding it automatically - which is the proper way to integrate with Hibernate from version 3.1 onwards. This is why you need to remove that setting from your "hibernate.cfg.xml" file if it conflicts with what you're actually trying to achieve... Juergen
  83. Re: clarification[ Go to top ]

    I'm not sure I understand correctly: Legacy code that doesn't know about Spring at all shouldn't need to participate in Spring-managed transactions either, so you're free to specify any Hibernate CurrentSessionContext class there.
    Yes, and so most users will have no problems.
    If, on the other hand, you do want that code to participate in Spring-managed transactions (e.g. using Spring's HibernateTransactionManager), then you need to use the SpringSessionContext class - since it doesn't make sense to use any other Session management strategy then.
    The legacy code checks if a transaction/session is already started by a "outer component". If so, it leaves the transaction/session management to the "outer component". But if not, it tries to create a new session/transaction. So I need both, participate and create sessions/transactions. Participating in spring managed transactions works fine. Unfortunately SpringSessionContext doesn't create a new session when the legacy code calls SessionFactory#currentSession().
    This choice was the same with Spring 2.0, actually. The only difference being that Spring 2.0 always used its own Session management unless you explicitly switched it off, no matter what "current_session_context_class" you specified in your Hibernate configuration. Spring 2.5 honors that Hibernate setting now, not overriding it automatically - which is the proper way to integrate with Hibernate from version 3.1 onwards. This is why you need to remove that setting from your "hibernate.cfg.xml" file if it conflicts with what you're actually trying to achieve...

    Juergen
    For sure you are right and its the fault of my architecture. But the legacy code worked with the old settings and doesn't work with the 2.5 required settings.
  84. Re: clarification[ Go to top ]

    One thing I haven't seen many people point out is that using DI and proxies make it harder to debug. Recently I had to debug some complex services, but it was rather painful because of all the proxies. In the situation where DI isn't used, debugging and stepping through the code on the server side is simpler since there's isn't any proxies.
    Just configure your debugger to skipp all painful classes.
  85. Re: clarification[ Go to top ]

    I've mainly worked on complex applications where all transactions have sub transactions or complementry transactions. In those cases, I don't believe the semantics defined in Spring's transaction API make complex transctions easier.
    Spring declarative transaction semantics are a superset of EJB declarative transaction semantics. The difference narrowed with EJB 3.0, which adopted the idea of "rollback rules" from Spring (in a less flexible way), but it's still significant. Of course if you need complementary transactions, you are going to need to do hard work yourself regardless: no transactional component model is going to be particularly helpful. Rgds Rod
  86. Re: my bias 2 bits[ Go to top ]

    Peter I don't think that were comparing apples to apples here. Spring is a development framework and as such its primary focus is to reduce the complexity and improve the level of productivity as well as provide means to abstract the business logic from the underlying implementation in order to enable flexibility and avoid implementation lock-in. As such it took very different role then most of the J2EE application servers that tried to cover both the development framework and the runtime implementations. For us (GigaSpaces) Spring provided an extremely extensible environment that enabled us to provide enhanced runtime capabilities and inject them to applications with minimal impact on the application business logic code. The consistent programming model also enabled us to provide simple programming model and development model that is consistent in how you deal with transactions, remoting, events, exceptions etc. We tried to do that directly with J2EE AppServers before but i found that in most cases the specs where too tight to specific implementation semantics or were simply missing. I therefore found it hard to plug-in alternative implementations to existing application servers with the way you deal with messaging, data, remoting or transactions. It is this flexibility and extensibility design that enables us to introduce totally new capabilities to the other middleware alternative still keep those changes outside of the application business logic. For example we took a POJO driven bean and turn into a virtual service that span across multiple machines and use remoting to abstract the physical location of those individual instances from the client that interact with them. Try doing that with standard J2EE servers. So for me Spring is much more then EJB or J2EE its a complete productive and extensible development framework and as such i see very little in the J(2)EE that comes close to what it provides. Nati S. GigaSpaces Write Once Scale Anywhere
  87. Long live Spring[ Go to top ]

    I started using spring back in 2004 and that brought a lot of good design/architecture to the projects I worked with, cleaning up the design and reducing the number of lines of code I had to write, and thus complexity. It solved many issues I always found to be a problem with enterprise programming in Java (ejb or not). To name a few: * it abstracted the Database/DAO/ORM exceptions to a unified unchecked (not mainstream by that time) exception hiearchy. Finally, I did not have to catch database exceptions in my business objects just to rethrow them as business exceptions; * the DI features let me write really decoupled components, resulting in really unit testable components; * implemented the pattern of holding db connections in a thread local, automatically bounded to the transaction by the tx proxy: I had never come across that technique before and I never liked passing connections around as I´ve always seem in DAO patterns before that; * the JDBC and other template classes solved the issue of having try/catches all around every single SQL statements, leaving connections openned and so on. I could put much more there, but my point is that I really learned a lot from Spring: the patterns/ideas expressed there are simply amazing. The framework itself is very well supported/documented and people on the foruns are usually very helpful and responsive. For all that, I really wish Spring/Springsource the best in their business: IMO, this really means very talented software developers being successful in the software market.
  88. Re: my bias 2 bits[ Go to top ]

    I agree that Spring vs existing java specs are two different approaches. Rather than define everything up front, Spring is more flexible in some respects. I still don't buy the idea that Spring is inherently better in and of itself. I can just as well use tomcat without Spring and add pieces as needed. Using dependency injection properly is very powerful, but I think not many people are pointing out when it breaks down and when it's not appropriate. I'm more interested in when something breaks. Once you break something, it starts to get much more interesting. it's just my opinion. peter