Discussions

News: Bob Lee: I Don't Get Spring

  1. Bob Lee: I Don't Get Spring (246 messages)

    Bob Lee issues a critique of the Spring Framework in "I Don't Get Spring," saying that despite claims, it's not lightweight, it is invasive to the code, doesn't support scopes (although scope support is planned)... in a lot of ways, he's saying that Spring offers a lot of support that people don't need, and advocates are often unclear as to what the specific advantages of Spring are, compared to other dependency injection containers.
    I can't tell you how many times I've had a developer tell me, "I used Spring on my last project and it worked really well," without being able to articulate what exactly they like about it or how it actually helped them. So far as I can tell, they like setter injection because it makes their code more flexible and testable, but that doesn't necessitate Spring. I guess for those who don't have the "dependency injection" mindset ingrained, using a framework that encourages (forces?) you to do the right thing helps. This encouragement doesn't outweigh the laundry list of negative impacts Spring has on your code though.

    The Spring folks openly snub their noses at J2EE, but from what I can tell Spring isn't exactly lightweight and simple either. The Javadocs are unnecessarily overwhelming. Does all of this really belong in a user API? At least J2EE cleanly separates API from implementation. Spring advocates tout that Spring doesn't "touch" your code, i.e. you don't have to implement any Spring-specific interfaces (with the exception of life-cycle interfaces, etc.). News flash: the XML configuration is my code, and from what I can see it often ends up constituting a lot of code, all of which is Spring-specific.
    It's worth a look - Spring is certainly the most visible IOC container out there, and some of the ideas behind IOC are becoming part of Java, Enterprise Edition, but critiques are certainly rare.
    Fortunately, simply adopting dependency injection design patterns gets you 90% of the way, further if you don't need encouragement to do the right thing. That's the approach I recommend. I certainly don't see myself adopting Spring anytime soon. I'm better off without it. If you do, go in with your eyes wide open. Be skeptical, critical. Just because someone has a popular Open Source framework, they have slick marketing, and they're supported by a big vendor (IBM pushed Struts on me for a number of years after all), it doesn't necessarily mean they know what's best for you or even that they know better than you.
    Is Spring really that good, that few can find actual substantiated flaws in its design? (Implementation issues are something else. Bug reports and inefficiencies in the framework get fixed over time, and don't normally affect most users.) The comments are also interesting, with both Spring users and Spring nonbelievers weighing in. What are the quantitative advantages or disadvantages of Spring for you?

    Threaded Messages (246)

  2. Bob Lee: I Don't Get Spring[ Go to top ]

    I use Spring for 2 years now and if you use ONLY the parts that you really need it is fantastic, but if you overuse him, you will have an complex solution for an simple application.

    If you know what parts of Spring to use you will not have problems IMHO.
  3. Bob Lee: I Don't Get Spring[ Go to top ]

    I use Spring for 2 years now and if you use ONLY the parts that you really need it is fantastic, but if you overuse him, you will have an complex solution for an simple application.

    I have to agree. I recently used Spring MVC on a project that had previously used Struts (painful) and Spring MVC worked out really well. However, the project only used a subset of Spring MVC's features.

    I think the general point with any of these frameworks is that you should use what you *NEED* rather than trying to use every aspect of the framework in your projects just for the sake of it (I have seen people do this too many times).

    Cheers,

    Andy Grove
    FireStorm/DAO 3.0 Generates Java code from relational schemas
  4. I got Spring[ Go to top ]

    I'm by no means an expert enterprise developer. As most of the people I know.

    I recently (really!) have discovered Spring. Of course I had heard about it, but I always thought "just another xmlish framework". But then I tried it and I really liked what I saw.

    These are, in my opinion, the advantages of using Spring:

    1.- Don't reinvent the wheel.
    I have done "service registries", jdbc and hibernate templates, factories, ... before. All sorts of plumbing I probably like to do. Or liked to. But I'm not getting paid to do that, I'm getting paid to solve problems.

    2.- Simplification.
    I must admit it. I'm an average programmer. My solutions to the problems that Spring solves are not as good as theirs, simply put. Their solutions work. And are _simple_ to use. Really nice.

    3.- Standarization.
    What happens when you introduce a new developer in your team? You have to train him/her. You have to write a lot of documentation. With Spring you only have to buy a book and tell him: "we use Spring for the declarative transactions and Acegi for the security". Period. If you don't understand something just google for it. Or ask somebody.

    4.- Good programming model
    Of course you don't need Spring to teach you how to do things. I probably need (have I said I'm an average programmer?) but, definitely, novice programmers beneficiate from it.

    Of course you don't need Spring to apply DI patterns. You definitely don't need Spring to use the Spring utility clases. They are javabeans, after all. But frankly: do you need to develop your own solutions to this mundane problems?

    I decided that I can invest my time better. And my company's money.
  5. I got Spring[ Go to top ]

    I'm by no means an expert enterprise developer. As most of the people I know.I recently (really!) have discovered Spring. Of course I had heard about it, but I always thought "just another xmlish framework". But then I tried it and I really liked what I saw.These are, in my opinion, the advantages of using Spring:1.- Don't reinvent the wheel. I have done "service registries", jdbc and hibernate templates, factories, ... before. All sorts of plumbing I probably like to do. Or liked to. But I'm not getting paid to do that, I'm getting paid to solve problems.2.- Simplification.I must admit it. I'm an average programmer. My solutions to the problems that Spring solves are not as good as theirs, simply put. Their solutions work. And are _simple_ to use. Really nice.3.- Standarization.What happens when you introduce a new developer in your team? You have to train him/her. You have to write a lot of documentation. With Spring you only have to buy a book and tell him: "we use Spring for the declarative transactions and Acegi for the security". Period. If you don't understand something just google for it. Or ask somebody.4.- Good programming modelOf course you don't need Spring to teach you how to do things. I probably need (have I said I'm an average programmer?) but, definitely, novice programmers beneficiate from it.Of course you don't need Spring to apply DI patterns. You definitely don't need Spring to use the Spring utility clases. They are javabeans, after all. But frankly: do you need to develop your own solutions to this mundane problems? I decided that I can invest my time better. And my company's money.

    You said a mouthful with that book comment. When someone starts, I have to explain what code we have that uses Struts, Spring, and Hibernate, but that's it. If you want to understand how to do a bi-directional mapping for your domain object or use a BeforeAdvice, here's your Hibernate and Spring book.
  6. Bob Lee: I Don't Get Spring[ Go to top ]

    I can only agree with Bob Lee. The only motive I see to support using Spring is all the helper/template classes it comes bundled with.

    Replacing a J2EE app configured through various XML files and clear-cut interfaces with a Spring app configured through various XML files without clear-cut interfaces... and with dependencies that way as much as a small container (which you're going to need anyway)?
  7. Bob Lee: I Don't Get Spring[ Go to top ]

    People who end up with a massive xml file usually do because they instanciate to much via IoC. Just use it where you would generally use a factory. Usually to connect the application layers and to adress cross-cutting concerns (config, log, security, ...) if you don't use AOP. I have reduced my last application code by around 30% just by using Spring and it's *malicious* xml files.

    On a side note, I would like Spring to support something like the JSF EL managed bean syntax. It would help to improve the xml config file readability.
  8. I do get Spring[ Go to top ]

    What are the quantitative advantages or disadvantages of Spring for you?

    I think the advantages of Spring are significant. It is far more than just an IoC container. It simplifies things like persistence, messaging, transactions, AOP, security.

    As for the 'XML is part of my code' argument in the article, well that is a reasonable point, but I find the XML very clear and easy to understand and maintain.

    Finally, I think Spring has great support for alternative approaches. It has little of the 'attitude' I have seen with many other frameworks. For example, if you if you don't want to use Spring MVC, you are given support for a range of other APIs. If you don't want to use Spring AOP you can use other products.

    I find that Spring makes so many things so much simpler.
  9. I do get Spring[ Go to top ]

    As for the 'XML is part of my code' argument in the article, well that is a reasonable point, but I find the XML very clear and easy to understand and maintain.
    Do you find it just as "clear and easy" to read through the code, stumble upon a missing piece of logic which, hey, was extracted out into a "nice" XML and go wandering around, looking for which XML file from the enormous number of those (from all these fancy frameworks) is what you are looking for in? Then returning back to the initial Java code and continuing the reading...

    Zero-config rulz!
    Finally, I think Spring has great support for alternative approaches. It has little of the 'attitude' I have seen with many other frameworks. For example, if you if you don't want to use Spring MVC, you are given support for a range of other APIs. If you don't want to use Spring AOP you can use other products.I find that Spring makes so many things so much simpler.
    Well, that or maybe it has much bigger attitude, than the other wanting to be a Jack-of-all-trades tool? Watch Spring marketing: "it integrates with this, that, and those others, too". That's some attitude :)
  10. I do get Spring[ Go to top ]

    Do you find it just as "clear and easy" to read through the code, stumble upon a missing piece of logic which, hey, was extracted out into a "nice" XML and go wandering around, looking for which XML file from the enormous number of those (from all these fancy frameworks) is what you are looking for in? Then returning back to the initial Java code and continuing the reading...Zero-config rulz!

    I don't extract logic into XML, only relationships.

    You may call me old fashioned, but after much consideration, I have decided that I actually like configuration. I usually find that making things explicit can make things easier to understand - you can follow explicit rules rather than trying to remember implicit ones.
    Well, that or maybe it has much bigger attitude, than the other wanting to be a Jack-of-all-trades tool? Watch Spring marketing: "it integrates with this, that, and those others, too". That's some attitude :)

    I would call it 'anti-attitude' :) I would consider 'attitude' in the context of frameworks to mean a tendency to dictate way of doing things and to imply that other approaches are somehow less valid. Spring seems to say 'do it any way you like'. It may be marketing, but it works for me.
  11. I do get Spring[ Go to top ]

    As for the 'XML is part of my code' argument in the article, well that is a reasonable point, but I find the XML very clear and easy to understand and maintain.
    Do you find it just as "clear and easy" to read through the code, stumble upon a missing piece of logic which, hey, was extracted out into a "nice" XML and go wandering around, looking for which XML file from the enormous number of those (from all these fancy frameworks) is what you are looking for in? Then returning back to the initial Java code and continuing the reading...Zero-config rulz!
    Finally, I think Spring has great support for alternative approaches. It has little of the 'attitude' I have seen with many other frameworks. For example, if you if you don't want to use Spring MVC, you are given support for a range of other APIs. If you don't want to use Spring AOP you can use other products.I find that Spring makes so many things so much simpler.
    Well, that or maybe it has much bigger attitude, than the other wanting to be a Jack-of-all-trades tool? Watch Spring marketing: "it integrates with this, that, and those others, too". That's some attitude :)

    Indeed. It's call do it your way, not our way.
  12. I think it makes no sense to discuss a complex conglomerate of diverse technologies such as Spring in terms of general abd broad statements. Hence here is my one concrete favourite in favour of Spring:

    Spring allows me to write data access objects that work (unchanged and with comparable transaction semantics) in an EJB container, in a web container and outside the container from unit tests. Do achieve this, it builds on its dependency injection and AOP facilities.

    Spring certainly isn't the only framework to achieve this, but it's very good at it, readily available and widely used.

    Once I find a credible alternative for this use case, Spring will likely become dispensable for me (despite all the other nice features it offers). It might be that the combination of EJB 3 entities and an "EJB 3 microcontainer" such as the JBoss embedded EJB 3 container will provide this alternative...

      cheers,
      gerald

    http://www.gerald-loeffler.net
  13. Bob Lee: I Don't Get Spring[ Go to top ]

    Well, people don't often do the right thing ;-). Its easy when you are part of a small team. But imagine when the team gets better, and projects get unwieldly. We are actually starting to migrate our home grown (yes home grown, but we planted the seeds before spring and because avalon at the time was too icky) ioc bootwork to spring, and to only use the parts as mentioned that we need. Even still, we've been able to mix and match our ioc bootwork with spring in mule quite simply. I think the real question is what you gain by using spring. I can't speak to it directly, since we are just migrating although we've tracked it for a while. However, I can tell you that forcing people to create abstractions at key points within the microarchitecture pays huge dividends when you have to go back and add functionality to a big system 2 yrs after the fact.

    And why did IBM push struts on you ;-). Like everything else, using the right tool for the wrong job leaves bruises most of the time.

    I would have a look at the xbeans integration for the spring configuration that likes pretty sweet.

    If everyone did the right thing, there would be more of us taking courses to get our realtors license ;-).
  14. Bob Lee: I Don't Get Spring[ Go to top ]

    Well he's right, he doesn't get it.

    The one thing Spring cannot save you from is your own poor design choices and programming practices. That is the source of a lot of the pain people experience with Spring - eg bloated XML files happen because you made your dependency graph too fine-grained.

    On the other hand, if your design is good then Spring doesn't stand in your way. In contrast, J2EE very often gets in the way of good design.

    Finally if you're overwhelmed by the Javadocs then you haven't figured out that Spring is VERY cleanly modular. You can select only the parts you need and ignore the rest. The Javadocs are big purely because there is a lot of functionality that you could use if you wanted to.
  15. He's right about being skeptical about things.

    I love Spring. I worked a lot with J2EE before it and I know it's value.

    So I'm a bit skeptical of Bob so I did a Google search.

    Seems he has worked on his own aop project.

    <strong>http://weblogs.java.net/blog/crazybob/archive/2004/02/dynaop_10_beta.html
    </strong>
    And It seems critics of Spring also helped.
    Thanks to Hani.... and my team for their invaluable feedback and support.

    Yea be skeptical. I agree on that.
  16. He's right about being skeptical about things.I love Spring. I worked a lot with J2EE before it and I know it's value.So I'm a bit skeptical of Bob so I did a Google search.Seems he has worked on his own aop project.<strong>http://weblogs.java.net/blog/crazybob/archive/2004/02/dynaop_10_beta.html<;/strong>And It seems critics of Spring also helped.Thanks to Hani.... and my team for their invaluable feedback and support.Yea be skeptical. I agree on that.

    For the record, your hero Hani agrees with Bob (according to his comments on Bob's blog entry). I disagree with Bob.

    Second, how does being a brilliant expert negate ones opinion on a subject?

    I am so sick of conspriacy theories anytime someone has a different opinion.

    Try again.
  17. He's right about being skeptical about things.I love Spring. I worked a lot with J2EE before it and I know it's value.So I'm a bit skeptical of Bob so I did a Google search.Seems he has worked on his own aop project.<strong>http://weblogs.java.net/blog/crazybob/archive/2004/02/dynaop_10_beta.html<;/strong>And It seems critics of Spring also helped.Thanks to Hani.... and my team for their invaluable feedback and support.Yea be skeptical. I agree on that.
    For the record, your hero Hani agrees with Bob (according to his comments on Bob's blog entry). I disagree with Bob.Second, how does being a brilliant expert negate ones opinion on a subject?I am so sick of conspriacy theories anytime someone has a different opinion.Try again.

    I fully agree that people should be allowed to express different opinions, but what is important is the points they put forth as their arguments but not who they are.

    Bob may be a brilliant developer and may have something up his sleeve but in this case i don't get his argument. Maybe he's got a point but is somehow failing to put it across clearly and probably that's why some people say he is on ego trip.

    One thing for certain is that Spring is not perfect and it will never be perfect. But it is the best choice most of us have right now and the number of people defending it and using it with success are a testament to this.

    Even though Spring is not perfect, the good thing about it is that its developers are open to critisim (constructive) and are always looking to improve the framework.But again you can't always please everyone.

    But again if Bob doesn't get spring people shouldn't try to villify him or shove Spring down his throat as there are other ways of skinning a cat.
  18. But again if Bob doesn't get spring people shouldn't try to villify him or shove Spring down his throat as there are other ways of skinning a cat.

    Please don't skin me. ;)

    My problem is more with the people who try to push Spring in every context without truly understanding exactly what problems they're solving than with Spring itself.

    I would venture to say that 95% of the Spring supporters on this list fit into that category, as I expected. It's much easier to write me off and say that I don't get it than it is to think more deeply about the problem. Plus, you don't risk having to admit you were wrong. It's so much more fun being right; that's what's important.

    P.S. Bruno, please stop spamming the discussion. You are not in the other 5%.
  19. He's right about being skeptical of things[ Go to top ]

    But again if Bob doesn't get spring people shouldn't try to villify him or shove Spring down his throat as there are other ways of skinning a cat.
    Please don't skin me. ;) My problem is more with the people who try to push Spring in every context without truly understanding exactly what problems they're solving than with Spring itself.I would venture to say that 95% of the Spring supporters on this list fit into that category, as I expected. It's much easier to write me off and say that I don't get it than it is to think more deeply about the problem. Plus, you don't risk having to admit you were wrong. It's so much more fun being right; that's what's important.P.S. Bruno, please stop spamming the discussion. You are not in the other 5%.

    I wasn't willing to play the ego card, but come on!! How smug is that to believe that just because people don't agee with you, that they haven't more deeply than you about Spring's place in their code.

    Perhaps I know my projects, my people, my deadlines better than you. And perhaps something can be popular because other people, most like as sharp as you are proported to be can acutally disagree with you and still have a full understanding of their situation.

    I haven't seen anything offered by you or the bandwagon fans your post has attracted that shows anything beyond "Look at me!! I am a rebel! How smart I am for not using <feel in the blank>."
  20. He's right about being skeptical of things[ Go to top ]

    I wasn't willing to play the ego card, but come on!! How smug is that to believe that just because people don't agee with you, that they haven't more deeply than you about Spring's place in their code.

    I don't believe that. I just made an observation about the numerous counter arguments, most of which haven't addressed any of my original points.
    Perhaps I know my projects, my people, my deadlines better than you.

    I'm sure you do. I said that in my post! Use Spring if you like, but please don't force it on me. Who are the real rebels here?

    You act as if my post came out of nowhere when in actuality it's in response to the constant berating I recieve from Spring fans. Now instead of having the same hour long discussion over and over on an individual basis, I can just point the next guy to my post.

    If you don't, "try to push Spring in every context without truly understanding exactly what problems [you]'re solving," then my comment wasn't directed at you.
  21. Please don't skin me. ;)

    LOL. You obviously know you're not the cat in this case,the problem we are trying to solve is ;)
  22. But again if Bob doesn't get spring people shouldn't try to villify him or shove Spring down his throat as there are other ways of skinning a cat.
    Please don't skin me. ;) My problem is more with the people who try to push Spring in every context without truly understanding exactly what problems they're solving than with Spring itself.I would venture to say that 95% of the Spring supporters on this list fit into that category, as I expected. It's much easier to write me off and say that I don't get it than it is to think more deeply about the problem. Plus, you don't risk having to admit you were wrong. It's so much more fun being right; that's what's important.P.S. Bruno, please stop spamming the discussion. You are not in the other 5%.

    I didn't find any real arguments in your blog to stop using Spring. It was sounding more like a personal attack and you just prove it with your last post. Instead of trying to explain your concerns about Spring you flames who actually like it. I would be interested to hear what is your solution? Static factories, I have been there and I pass. Your own framework? What the difference between your and Spring?

    Having followed this thread I haven't seen any real arguments against Spring itself, just people discrediting it but not backing their point with technical arguments. At least, people against DI try to prove their point even if I totally disagree with what they say. It's typical, some people always spit on what is popular and discredit everyone who actually likes it. You can see that in music, in OS, in car, sport, ...
  23. Bob Lee: I Don't Get Spring[ Go to top ]

    That post is so incredibly flawed that just trying to think where to start from in order to debunk it gives me headaches.

    First of all the fact that he argues that Spring is "not lightweight" because the creation pipeline of a bean through a Spring container is not optimized as he thinks it should be is incredible. It seems obvious to me that the original claim of "lightness" was with respect to J2EE EJB containers: the fact that the J2EE standard is going in a better direction and many containers have worked to ease the pain of EJB programming does not justify such a blatant lack of correctness in the analysis.

    Anyway, creating a java object with a new and asking a Spring factory for a bean seems to me two very different kind of activities, and I find that a Spring bean factory does well its job with the features one would need from an ioc container. Bob Lee "does not get" what an IOC container is useful for, but I don't really see a "real" reason in his argument: saying that the XML config in Spring is "xml programming" is completely out of target.

    You may say Spring's XML config is... XML, and if you consider XML to be the root of all evil, then Spring config is evil. JEE does not do much better in this regard: on the contrary there are approaches one can follow in order to extend spring configurability, I for one explored a way (here: http://java.stratosfera.it/page/javasfera/20050422#a_couple_of_ideas_on ), and then decided that I could stick with XML (especially now that I can expect IDEA to support me).

    Then he comes with the claim that Spring is "not simple", he feels lost without guidelines about how to structure is app (only coarse grained beans managed in Spring or not?), the javadocs contain too much information (!), he complains that if you use a Spring container (in a standalone app, I suppose) you have to call it once in order to extract the first object because he's afraid that the id of that first object in the java version may lose sync from the XML version... come on, is this a technical reason not to like Spring?!? Do you really mean you want a completely formalized world? Didn't you use something like velocity, expression languages, freemarker or things like that, in the past?

    Wouldn't this be a better target for such kinds of remarks? And then he complains about autowiring: people would complain if Spring didn't provide autowiring, but since it does there's someone that complains because Spring has too much features (as if one had to pay for them): isn't this the most clear indication that this post sprang out of a night without sleep due to bad digestion?

    There is a "framework" part in Spring that deals with wiring and structuring your app, and that part certainly allows to build apps in a "non-springified" way: I think a totally transparent framework having no programming model, no visible components, no custom configuration wouldn't be a framework. Spring config is consistent, simple, powerful enough (and it's becoming more powerful in 2.0, and I'm not convinced at all it was needed). Could we do without? Certainly, but we would have to code the same structuring code, deal with dependencies, deal with lifecycle, deal with transactional configuration in j2ee descriptors, deal with the lack of components spring provides.

    What people have found is that the model spring offer is easy to grasp, powerful, flexible, rich: these are just adjectives, but each one of them translates in a number of experiences every Spring user has had in the past, just discovering clever ways to do things with the framework or the library tools it provides (and that's because a number of classes may be needed, because Spring does not only provide a "transparent" framework, but also utility libraries, implementation starting points and so on.

    The author speaks of "dangerous and blind increase" in Spring adoption. Dangerous to whom, exactly? Blind? I can understand that someone can be skeptical when such a massive movement rises from nothing in a couple of years, but what I would have done if I had been in his shoes would be ask someone that uses Spring the reasons why he finds it useful. There's a nice community, at forum.springframework.org, I'm sure Bob Lee could ask for pieces of advice about how to use bean factories, and also give his opinions about how bloated the spring javadocs are...
  24. Bob Lee: I Don't Get Spring[ Go to top ]

    The Spring folks openly snub their noses at J2EE, but from what I can tell Spring isn't exactly lightweight and simple either.

    I'm looking at the Spring Framework website right now, assuming I'm missing something, and see no indication of JEE being "snubbed" -- perhaps Mr. Lee will clarify this?

    Perhaps the book reviews have something? Nope -- not there either...

    It took me under 2 hours to understand Spring, when you compare that with the amount of time it's taken me to learn JEE, the difference is significant.

    Thomas
  25. Bob Lee: I Don't Get Spring[ Go to top ]

    This is not a flaw in Spring, but a side effect how people use it:

    One of the problems I have seen from people getting comfy with Spring is that they start to design their classes to work with Spring instead of treating Spring as 'invisible' plumbing. You see setters being lavishly added to classes when a constructor is the right approach from a design perspective, for example.

    Another thing is the use of Spring's own interfaces and classes for binding into Spring's supported features like JDBC templates, JMS templates. I tend to wrap these behind my own interfaces so I can drop the Spring dependencies if I have to. If you do this, I don't think Spring is going to take a stranglehold over your software. It's like working with anything else.
  26. Bob Lee: I Don't Get Spring[ Go to top ]

    This is all too funny. I use J2EE and I happen not to need Spring. I have set things up so I can do what I need to do without the technology getting in my way. I solved these problems before Spring existed or at least before I became aware of it. Others have used Spring to solve the same problems I solve in other ways or to solve problems I haven't had to face yet.

    I appreciate and agree with Spring's defenders when they advise that you should only use only the parts you need and you should use it correctly. You could say the same thing about J2EE or other standards and frameworks and be equally correct. Misunderstanding and misuse almost always creates problems.

    What is so funny to me is how many people become so rabidly passionate for or against some framework or standard. Why get so worked up? If you like it, use it, if not don't.

    I'll say one thing for Spring - at least its open source and not proprietary so its unlikely that its advocates are being manipulated by some evil force.
  27. Bob Lee: I Don't Get Spring[ Go to top ]

    Bob, from what I read into your blog, it's exactly as you say: You don't get Spring :-). It's questions after questions which I suppose the spring guys will answer.

    I'll tell you what's the most used by me feature of Spring: Transaction abstraction and the AOP features. Actually I think that what I like the most is the AOP part. It enables a "human" like AOP, nothing complicated, I've found that in the day to day development I use 90% interceptor like constructs and the rest I would use full blown AOP semantics ala AspectJ, which BTW will come into Spring.

    Don't get me wrong, it's not a critique, it's just that it helped me alot with a lot of configuration and plumbing you usually do in application code. Also I've used not once integration with the different OS frameworks out there like Quartz, etc.

    Overall it helped much more than it did wrong.
  28. Bob Lee: I Don't Get Spring[ Go to top ]

    Bob, from what I read into your blog, it's exactly as you say: You don't get Spring :-). It's questions after questions which I suppose the spring guys will answer.I'll tell you what's the most used by me feature of Spring: Transaction abstraction and the AOP features. Actually I think that what I like the most is the AOP part. It enables a "human" like AOP, nothing complicated, I've found that in the day to day development I use 90% interceptor like constructs and the rest I would use full blown AOP semantics ala AspectJ, which BTW will come into Spring.Don't get me wrong, it's not a critique, it's just that it helped me alot with a lot of configuration and plumbing you usually do in application code. Also I've used not once integration with the different OS frameworks out there like Quartz, etc.Overall it helped much more than it did wrong.

    And btw, it looks like a development platform. You can really focus on business letting transactions, configuration and tons of integration code with the other OS packages INSIDE the framework. And yes, to me is lightweight having in mind you get all you get from a 2M jar (+other OS libs whatever you use) and a servlet container. As for the javadocs, I prefer them to be too long than too short.

    But with the XML I agree. They should (and they did as of Spring 2.0) make them as brief/short as possible.
  29. Bob Lee: I Don't Get Spring[ Go to top ]

    Fortunately, simply adopting dependency injection design patterns gets you 90% of the way, further if you don't need encouragement to do the right thing. That's the approach I recommend.

    I'm following you, Bob, but in the end I think this argument, and most of your follow-up discussion in the blog entry, sounds a lot like:

    What's so great about Hibernate? I guess for people who can't write their own persistence framework, it must be OK.

    and:

    Why are all these guys using Webwork? It's not that hard to write a freaking MVC framework, and I could do a lot better anyway.

    When you are doing enterprise development, it is not always trivial to keep your dependency injection pure. You are dealing with a lot of third-party libraries, and integrating with a lot of legacy code, and the factory and configuration scenarios can get tricky sometimes. It starts getting very tempting under a deadline to say, "Aw **** it, I'll just throw in a new ConcreteImpl() here."

    Spring offers a lot of prebuilt factories and aspects, and a lot of preimplemented integration with popular third-party frameworks. It is much easier to keep your team on track with sound design principles when you can just grab one of these off the shelf instead of saying, "OK, guys, let's step back for a minute and think of how we are going to build support for this in our homegrown DI framework."

    Perhaps your response is, "Look, if you know anything about DI, you could just build all of your Hibernate support, Transaction Management support, OSWorkflow support, Webwork integration, property-based factories, integration with crappy legacy service locators, performance monitoring interceptors, caching interceptors, and selective use of autowiring yourself." And I would say, "No, thank you."
  30. Bob Lee: I Don't Get Spring[ Go to top ]

    Fortunately, simply adopting dependency injection design patterns gets you 90% of the way, further if you don't need encouragement to do the right thing. That's the approach I recommend.
    I'm following you, Bob, but in the end I think this argument, and most of your follow-up discussion in the blog entry, sounds a lot like:What's so great about Hibernate? I guess for people who can't write their own persistence framework, it must be OK.and:Why are all these guys using Webwork? It's not that hard to write a freaking MVC framework, and I could do a lot better anyway.When you are doing enterprise development, it is not always trivial to keep your dependency injection pure. You are dealing with a lot of third-party libraries, and integrating with a lot of legacy code, and the factory and configuration scenarios can get tricky sometimes. It starts getting very tempting under a deadline to say, "Aw **** it, I'll just throw in a new ConcreteImpl() here."Spring offers a lot of prebuilt factories and aspects, and a lot of preimplemented integration with popular third-party frameworks. It is much easier to keep your team on track with sound design principles when you can just grab one of these off the shelf instead of saying, "OK, guys, let's step back for a minute and think of how we are going to build support for this in our homegrown DI framework."Perhaps your response is, "Look, if you know anything about DI, you could just build all of your Hibernate support, Transaction Management support, OSWorkflow support, Webwork integration, property-based factories, integration with crappy legacy service locators, performance monitoring interceptors, caching interceptors, and selective use of autowiring yourself." And I would say, "No, thank you."

    I think you hit the nail on the head. Spring is an excellent IoC container, but it is a lot more than that. The support it provides is support you don't have to write. It solves common problems in an elegant way.

    I've met Bob Lee and I think he is brilliant, but I don't agree with him about Spring.
  31. Bob Lee: I Don't Get Spring[ Go to top ]

    I'm at a lack of understanding why people keep posting things like...

    "Tim Shadel won't be using JSF", "Bob Lee hates Spring", etc...

    Who is Tim Shadel and Bob Lee, and hundreds of others that have their preferences. Why don't we just start posting everyone's opinion on this boards as a topic of discussion? Am I wrong here? Until the recent posts, I had no idea (nor did I care), that Tim Shadel and Bob Lee have an opinion. I mean, I'd be more willing to read Martin Fowler's, Rod Johnson, and myriad of other voices that I (and I'm sure many others) trust. This board is becoming like a blog advertisement agency.
  32. Bob Lee: I Don't Get Spring[ Go to top ]

    I'm at a lack of understanding why people keep posting things like..."Tim Shadel won't be using JSF", "Bob Lee hates Spring", etc...Who is Tim Shadel and Bob Lee, and hundreds of others that have their preferences. Why don't we just start posting everyone's opinion on this boards as a topic of discussion?

    Well said. It seems to me that such articles are posted simply to stir up controversy. I would prefer more positive and informative articles about technologies and strategies.
  33. Bob Lee: I Don't Get Spring[ Go to top ]

    I'm at a lack of understanding why people keep posting things like..."Tim Shadel won't be using JSF", "Bob Lee hates Spring", etc...Who is Tim Shadel and Bob Lee, and hundreds of others that have their preferences. Why don't we just start posting everyone's opinion on this boards as a topic of discussion?
    Well said. It seems to me that such articles are posted simply to stir up controversy. I would prefer more positive and informative articles about technologies and strategies.

    Well to sum it up, it worked perfectly with the Tim Shadel posting here on TSS, for some strange kind of reason the entire 260 postings discussion which followed did not turn out into a flamewar (although minor parts of it)

    But when I saw the article posting, I instantly thought to myself, great, the next endless discussion now has been triggered...

    I agree, I would love to have good blog links to Fowler, Clanahan etc... blogs, but not this I hate <fill in technology> here blogs, which are just posted to trigger discussion and traffic.
  34. Bob Lee: I Don't Get Spring[ Go to top ]

    I'm at a lack of understanding why people keep posting things like..."Tim Shadel won't be using JSF", "Bob Lee hates Spring", etc...Who is Tim Shadel and Bob Lee, and hundreds of others that have their preferences. Why don't we just start posting everyone's opinion on this boards as a topic of discussion?
    Well said. It seems to me that such articles are posted simply to stir up controversy. I would prefer more positive and informative articles about technologies and strategies.
    Ouch! The blogs mentioned were highlighted because sometimes a contrarian view is good to highlight what the *noncontrarian* views are - i.e., by finding an objection, you define your own position.

    That said, I also post news that people find relevant and forward to me, or highlight - which was the case in both Tim Shadel and Bob Lee's topics. In the summaries of both, an effort was made to point out the core points of their positions, to make sure that if one wasn't interested, one didn't have to read the entire post.

    Thanks for the input! I'll see what I can do to factor it in.
  35. Bob Lee: I Don't Get Spring[ Go to top ]

    Ouch! The blogs mentioned were highlighted because sometimes a contrarian view is good to highlight what the *noncontrarian* views are - i.e., by finding an objection, you define your own position.That said, I also post news that people find relevant and forward to me, or highlight - which was the case in both Tim Shadel and Bob Lee's topics. In the summaries of both, an effort was made to point out the core points of their positions, to make sure that if one wasn't interested, one didn't have to read the entire post. Thanks for the input! I'll see what I can do to factor it in.

    Joseph, I think the point we're trying to make is that fact that everyone has an opinion, and I'm just not sure how those two people (of whom I and I'm sure 99.99% of people who read this site have never heard of), qualify as a topic of discussion. I'm all for open opinions, but maybe in a format of actually sparking a discussion on a topic, say "Spring: pros/cons" and then the first reply could be say someone's opinion. I think all opinion's matter, but we tend to want to read the relevant ones. Ones from folks that have earned some sort of credibility within the specific domain. I think even posting someone's opinion on the topic is OK, as long as it's not titled "Bob Lee: I don't get Spring". Who cares if Bob gets Spring or not, we care about how masses are using Spring it's pros, cons, etc...

    That said, I'm also impressed that most of these posts never become a flame war, rather turn into productive discussions, with folks like Rod and Rob contributing their points of view.

    Ilya
  36. Bob Lee: I Don't Get Spring[ Go to top ]

    I'm all for open opinions, but maybe in a format of actually sparking a discussion on a topic, say "Spring: pros/cons" and then the first reply could be say someone's opinion.

    Absolutely. This is exactly my point. I did not want to sound too harsh (my apologies Joseph), but too many 'what is wrong with....' articles may give the wrong impression of the state of Java on a very visible forum. Debate is good and can be very productive, but it need not be triggered by negative posts like this. I agree with what Ilya has written here - apart from one thing:
    Ones from folks that have earned some sort of credibility within the specific domain

    Personally, I don't care who as written the article, as long as it is interesting.
  37. Bob Lee: I Don't Get Spring[ Go to top ]

    I agree with what Ilya has written here - apart from one thing:
    Ones from folks that have earned some sort of credibility within the specific domain
    Personally, I don't care who as written the article, as long as it is interesting.

    I knew no matter how I put it, someone will interpret it differently, that's my mistake:-) I actualy agree with you on that. I would read an article by anyone, as long as it makes sense and actualy teaches me something. I guess what I tried to say, was "Martin Fowler says: Spring sucks" would catch my attention a bit faster than Bob Lee says he doesn't like it. I'd read both though.

    Ilya
  38. Bob Lee: I Don't Get Spring[ Go to top ]

    I'm at a lack of understanding why people keep posting things like..."Tim Shadel won't be using JSF", "Bob Lee hates Spring", etc...Who is Tim Shadel and Bob Lee, and hundreds of others that have their preferences. Why don't we just start posting everyone's opinion on this boards as a topic of discussion? Am I wrong here? Until the recent posts, I had no idea (nor did I care), that Tim Shadel and Bob Lee have an opinion. I mean, I'd be more willing to read Martin Fowler's, Rod Johnson, and myriad of other voices that I (and I'm sure many others) trust. This board is becoming like a blog advertisement agency.

    You don't know who Bob Lee (Crazy Bob) is? You should.

    I don't agree with him about Spring, but Bob Lee is awesome.
  39. Bob Lee: I Don't Get Spring[ Go to top ]

    You don't know who Bob Lee (Crazy Bob) is? You should. I don't agree with him about Spring, but Bob Lee is awesome.
    I don't know who Bob Lee is either. Why should I ? Can his ego take it that somebody doesn't know who he is ?
    I don't know who you are either for that matter. This place if full of opinionated people who all seem to have some sort of attention deficiency problem.
  40. RE: This place if full of opinionated, ego-centric, ADD ridden...
    You don't know who Bob Lee (Crazy Bob) is? You should. I don't agree with him about Spring, but Bob Lee is awesome.
    I don't know who Bob Lee is either. Why should I ? Can his ego take it that somebody doesn't know who he is ? I don't know who you are either for that matter. This place if full of opinionated people who all seem to have some sort of attention deficiency problem.

    Bob Lee is a recognized expert who has written a lot and influenced quite a few other developers. He wrote one of the first AOP frameworks: DynaAop. I don't always agree with him, but I value his opinion.

    I don't know who you are, but am sure your mother thinks you are a special, unique person. (Tyler Durden: "You are not special. You are not a beautiful or unique snowflake. You are the same decaying organic matter as everything else" but aren't we all.... comes to mind.)

    Are you saying developers are opinionated? Shocking!
    Are you saying some developers have ADD? Shocking!
    Are you saying developers are egotistical? Shocking!

    I've hung out with Bob several times. He does not seem egotistical to me. He is confident for sure. I am sure his ego can withstand your lack of knowledge (also known as ignorance).

    Let me put it this way, your hero Rod Johnson knows who Bob Lee is. (Nothing against Rod...)

    Ignorance is not humility either. Your remarks smack a lot more like egotism to me.

    I don't think having an opinion different than the majority makes one egotistical.

    If I had to name the top 25 developers that I know of. Bob would be on that list. His point of view on Spring is newsworthy (although inaccurate as hell).

    Do you have an opinon on Spring?

    I do:
    http://jroller.com/page/RickHigh?entry=my_response_to_bob_lee

    --Rick Hightower
  41. Bob Lee: I Don't Get Spring[ Go to top ]

    I'm at a lack of understanding why people keep posting things like..."Tim Shadel won't be using JSF", "Bob Lee hates Spring", etc...Who is Tim Shadel and Bob Lee, and hundreds of others that have their preferences. Why don't we just start posting everyone's opinion on this boards as a topic of discussion? Am I wrong here? Until the recent posts, I had no idea (nor did I care), that Tim Shadel and Bob Lee have an opinion. I mean, I'd be more willing to read Martin Fowler's, Rod Johnson, and myriad of other voices that I (and I'm sure many others) trust. This board is becoming like a blog advertisement agency.

    You can't lump Bob Lee with Tim Shadel. Let's put it this way: Rod Johnson knows who Bob Lee is.

    Just for the record, I don't agree with Tim Shadel on JSF or Bob Lee on Spring.

    RE: This board is becoming like a blog advertisement agency. Um.. Err.. What is Bob trying to sell? He is a developer at Google, and is so far removed from any sales cycle.
  42. Bob... your resume says that:[ Go to top ]

    Mar. ’04 – Oct. ‘04 Plateau
    Architect
    - Helped re-architect the industry-leading (according to Gartner) learning management system (LMS)
    - Mentored architects on use of Spring and dynaop
    - Reviewed product code base

    http://crazybob.org/resume.pdf
  43. Bob... your resume says that:[ Go to top ]

    Hmmm, I woldn't be too proud of the rearchitecting of Plateau:-) I've worked with it for the last year and have designed various interfaces for it. It's a EJB intensive, struts-based application that has it's issues. I can't comment more on it, but he's opinion has just moved lower on my list.
  44. Bob Lee: I Don't Get Spring[ Go to top ]

    Who is Bob Lee? One of those increasing mass of Bloggers, who contribute to the ever increasing mass of "waste" information? Why do we read there blogs? Oh, yeah, because they have learnt the american why of self-promotion and selling.....
    "Everybody loves Spring", so we say "We don't get Spring", that will catch some 5 minute attention, oh yes then he "authoring" a aop programming framework... it's 1.0 beta, who's using it? Don't know. Self-Promotion? Probably...
    Sorry for getting probably somewhat rude, but i am also getting bitter... about the Ever-Better-knowing Bitter guys. Spring may have flaws, a constructive discussing of how to better Spring would be great, but's that's no eye catcher und the Spring community is doing that anyway......
    One of the most of the most convincing things about Spring, seems to me, if used correctly: You can reduce the dependency of your code to Spring to the absolute necessary and you can have large parts of your code compeletely independent of any J2EE Api....and actually implement "Rich" Domain Layers and Service Layers, which also don't have to know about Spring. And where you do use Spring code, i almost always found that the Spring API's reduce the code i would have write otherwise tremendously.
    Ok, you can say it doesn't have to be Spring ... real alternatives? Where do you have a IoC Container with such a rich set of supporting (convenience) API's?
    Or if Spring was'nt, the Java World would need it. We don't need fragmentation, but consolidation.
  45. Big Spring problem[ Go to top ]

    I found one big problem with Spring: inability to properly separate business configuration from IoC container configuration. Also, there is no support for environment specific configuration parts. Yes, you can have one master config common to all environments, and a separate per environment config, but this is not enough fine grained as a bean must be configured in one config as a whole.

    Ending up with (one or more) huge monolitic XML config file(s) which contain(s) bean wiring config mixed with business config (number of rows per page, for example) mixed with environment specific config (database connection parameters, for example) is no good.
  46. Big Spring problem[ Go to top ]

    I found one big problem with Spring: inability to properly separate business configuration from IoC container configuration. Also, there is no support for environment specific configuration parts. Yes, you can have one master config common to all environments, and a separate per environment config, but this is not enough fine grained as a bean must be configured in one config as a whole.Ending up with (one or more) huge monolitic XML config file(s) which contain(s) bean wiring config mixed with business config (number of rows per page, for example) mixed with environment specific config (database connection parameters, for example) is no good.
  47. Big Spring problem[ Go to top ]

    Mileta
     
    Ending up with (one or more) huge monolitic XML config file(s) which contain(s) bean wiring config mixed with business config (number of rows per page, for example) mixed with environment specific config (database connection parameters, for example) is no good.
    Spring has always supported the ability to use properties files for such simple configuration parameters, which often change at a different rate from structural information.

    And yes, we are always looking to listen to users and improve Spring. Spring 2.0 represents a lot of work, and (we believe) a big step forward in many areas, such as XML configuration and AOP.

    Rgds
    Rod
  48. Big Spring problem[ Go to top ]

    I found one big problem with Spring: inability to properly separate business configuration from IoC container configuration. Also, there is no support for environment specific configuration parts. Yes, you can have one master config common to all environments, and a separate per environment config, but this is not enough fine grained as a bean must be configured in one config as a whole.Ending up with (one or more) huge monolitic XML config file(s) which contain(s) bean wiring config mixed with business config (number of rows per page, for example) mixed with environment specific config (database connection parameters, for example) is no good.


    I believe that spring 2.0 addresses this problem. With early versions of spring you can create multiple xml files and merge them toegther @runtime. Each xml file could have different concerns ie. one file for resource information, one file for services, one file hibernate configurations,
    .. etc etc.
  49. Big Spring problem[ Go to top ]

    I found one big problem with Spring: inability to properly separate business configuration from IoC container configuration. Also, there is no support for environment specific configuration parts. Yes, you can have one master config common to all environments, and a separate per environment config, but this is not enough fine grained as a bean must be configured in one config as a whole.Ending up with (one or more) huge monolitic XML config file(s) which contain(s) bean wiring config mixed with business config (number of rows per page, for example) mixed with environment specific config (database connection parameters, for example) is no good.

    Mileta,

    Have you tried using the PropertyPlaceholderConfigurer for Spring? Most of our clients find that to be a really nice way to separate environment specific configuration from container/wiring/framework configuration.

    Rob
    ------------------------------------
    Interface21 - Spring from the Source
    http://www.springframework.com
  50. Spring is a factory[ Go to top ]

    Whenever I'm trying to explain Spring to someone, I end up boiling it down to: "Spring is a factory". Done and done.

    We've all known (or at least I hope we all know) that an interface pattern to complex objects is desireable - almost necessary, when you could have multiple possible implementations (which you should if you're unit testing - and I'm sure we're all doing that, right?).

    What do you do when you have an interface? You create a factory. And man, did we have a lot of factories. The end result was great! We had objects that could be accessed either directly, through JMS, or mocked up for unit testing other objects. But our client code only needed to worry about the interface - oh, yea - and that stupid factory.

    Then, Spring became our factory. It removed over 70% of our code (which was all fluf anyhow) so that all that was left was just our business logic. Sure, we have a lot of getters and setters, now - but Eclipse generates that for us and they're easy to filter out.

    And true - the XML file does get big - but it can be broken up into multiple files. And as for management - it <em>did</em> just move that 70% of code to an XML file. But in doing so, we now have reusable beans that we <em>most likely</em> would not have re-used before.

    Plus, redeploying an XML file is a heck of a lot easier than redeploying a java object - no recompilation necessary! This made configuration settings much easier to manage. No more properties files! We used spring as our properties container and injected the configuration setting directly into the appropriate objects.

    The biggest advantage to Spring that we've used is the ability to mock up implementations for unit testing. Again, we can take the dependencies of an object we're testing, and create mock objects and inject them in with out changeing a lick of code. When we're ready for production, we just wire them back together.

    I agree with the others here that Spring contains a lot of functionality that most people won't use - but the core functionality is very, very useful in and of itself.

    Let me put it this way - understanding Spring is not about understanding a "framework". It about understanding the "mindset". IOC is whole other paradigm. I wasn't sold on it at first. I kept asking the big "and what does this <em>do</em> for me?" Until I changed my "build it myself" mindset, I never got it. But having used it for almost a year now, I won't develop without it.
  51. Spring is a factory[ Go to top ]

    +1

    Yeah, that is kind of how I think of Spring (the IOC container). As a super-factory that replaces all the little XFactory classes you'd have to write for a clean API.

    On the other hand I don't see why people are jumping on poor Bob for having both an opinion and a few interesting things to think about. I mean the guy says right up front "I don't get Spring" and some goofballs write long frothy replies on how he should ridiculed for not getting it.

    I think Spring has a marketing problem. Since Spring is really set of frameworks under one name, just saying "I use Spring" means nothing. Much like when the idiot marketers at Microsoft started slapping the now meaningless .NET suffix on everything MS made. (Did we really need MineSweeper.NET?)

    I think it is important to say I use Spring IOC or I use Spring AOP or for Bob to say I don't understand Spring IOC.
  52. more xml is bad[ Go to top ]

    One of the reasons I've so far not used spring or similar solutions is that I hate having to learn about all these small xml files each with their own tags strucure and obscure problems.

    I would like to see 0 xml file solutions for the J2EE domain. Specifically I don't want to xmlifie my configuration, database schema, deployment settings, web service interface. Anything that requires me to edit things manually should be Java. I want a 100% java solution. The mistake people make is that moving all this stuff to xml moves the problem and obscures it at the same time. It doesn't solve the problem but adds to it.

    The newer stuff from sun seems to move away from XML as a silver bullet for everything and use annotations instead. Annotations are still too verbose IMHO but a lot better already.

    The reason application servers are so hard to work with is not that they are conceptually that complicated but that they require you to be familiar with dozens of xml based file formats that you will need to write or tinker with to get anything done. Most IDEs hide the problem with shiny wizards. But these wizards are only for the simplest of usecases.
  53. Re: more xml is bad[ Go to top ]

    One of the reasons I've so far not used spring or similar solutions is that I hate having to learn about all these small xml files each with their own tags strucure and obscure problems. I would like to see 0 xml file solutions for the J2EE domain. Specifically I don't want to xmlifie my configuration, database schema, deployment settings, web service interface. Anything that requires me to edit things manually should be Java. I want a 100% java solution. The mistake people make is that moving all this stuff to xml moves the problem and obscures it at the same time. It doesn't solve the problem but adds to it. The newer stuff from sun seems to move away from XML as a silver bullet for everything and use annotations instead. Annotations are still too verbose IMHO but a lot better already.The reason application servers are so hard to work with is not that they are conceptually that complicated but that they require you to be familiar with dozens of xml based file formats that you will need to write or tinker with to get anything done. Most IDEs hide the problem with shiny wizards. But these wizards are only for the simplest of usecases.

    Granted, Spring at it's core is not a "configuration framework", but it's a very important aspect. But remove Spring from the picture. How, then, do you propose to manage configuration? When you say using "annotations" - annotations are great, but how do you propose we manage the configuration? In the code? In an annotation? It seems like that's pushing annotations a little far for their design. Plus, where is this configuration going to be stored? If it's in code - good luck managing that in an enterprise application.
  54. Re: more xml is bad[ Go to top ]

    One of the reasons I've so far not used spring or similar solutions is that I hate having to learn about all these small xml files each with their own tags strucure and obscure problems. I would like to see 0 xml file solutions for the J2EE domain. Specifically I don't want to xmlifie my configuration, database schema, deployment settings, web service interface. Anything that requires me to edit things manually should be Java. I want a 100% java solution. The mistake people make is that moving all this stuff to xml moves the problem and obscures it at the same time. It doesn't solve the problem but adds to it. The newer stuff from sun seems to move away from XML as a silver bullet for everything and use annotations instead. Annotations are still too verbose IMHO but a lot better already.The reason application servers are so hard to work with is not that they are conceptually that complicated but that they require you to be familiar with dozens of xml based file formats that you will need to write or tinker with to get anything done. Most IDEs hide the problem with shiny wizards. But these wizards are only for the simplest of usecases.
    Granted, Spring at it's core is not a "configuration framework", but it's a very important aspect. But remove Spring from the picture. How, then, do you propose to manage configuration? When you say using "annotations" - annotations are great, but how do you propose we manage the configuration? In the code? In an annotation? It seems like that's pushing annotations a little far for their design. Plus, where is this configuration going to be stored? If it's in code - good luck managing that in an enterprise application.


    Well spring has been used for various reasons, given the startup times of app servers (which often have to be restarted in a hotplut debugging cycle) people usually or often prefer to develop on a lightweight container like Tomcat and later deploy the stuff on the clients app server.
    But the patterns which J2EE enforces (clear cut between the three layers within a business object facade enforced pattern) is valid and works. So many people simply moved on to spring.
    Another aspect simply was IOC, which is besides the missing scoping excellent, which is one step further of simply service location.
    Transactional control on configuration level without a full blown app server also was an issue.

    The third group simply liked to have the simplification Spring provides and the glue code to many J2EE libs.

    And another group was starting to use spring because it provided a sane handling of AOP without having to use precompilers (which was an issue a while ago)

    So there were many reasons why people started to use spring (for me it mainly was the ioc and aop stuff)
    and only few have stopped to use it as supportive layer on the application level.

    Is it more lightweight than a J2EE approach, yes and no, it is very similar to EJBs in the patterns it enforces, you do not have to use a full blown container though (which in EJB3 is also not an issue anymore)
    If you use many aspects of it, the complexity in spring and J2EE probably is very similar although on different angles because Spring tries to cover way much more.
    The trick is only use the part you need not everything.

    Does it make J2EE obsolete, definitely no, especially not with the stuff EJB3 brings on the table, but does make EJB3 spring obsolete, also a definite no, due to the fact that spring even can enhance EJB3 a lot with its supportive frameworks. (For instance now Gavin King will beat me for that, a DAO layer for EJB3 entitiy beans, etc...)
  55. Great post[ Go to top ]

    This is a great post and do you know why? Because it made all Spring fanatics so mad that they just had to post back everything that is good about Spring and thus enabled me to read up of Spring features and how to use them. :-)

    Regards Peter
  56. Re: more xml is bad[ Go to top ]

    Granted, Spring at it's core is not a "configuration framework", but it's a very important aspect. But remove Spring from the picture. How, then, do you propose to manage configuration? When you say using "annotations" - annotations are great, but how do you propose we manage the configuration? In the code? In an annotation? It seems like that's pushing annotations a little far for their design. Plus, where is this configuration going to be stored? If it's in code - good luck managing that in an enterprise application.

    JDNI, properties files, database records, ...? And do you really need the strategy pattern for all services you have, or do most of them actually will ever have just one implementation?

    I've been a Spring sceptic for a long time. I am just starting to like it, largely due to things like transaction support and the way it integrates with other frameworks (like that awesome Spring-Wicket integration build by Igor Vaynberg).

    Personally, I prefer small, focussed frameworks that do only one thing but do it really well instead of doing *a lot* and let you choose the bits and pieces. That said, Spring seems to be the de-facto standard for this IoC thing and it is really not difficult to use (the documentation makes up for the over-abundance of interfaces). There is a world without it, but if you need IoC, Spring is a good choice.
  57. When we need frameworks to configure our code, the real message is that the API's we use to build our apps are too complex. And, the environments we are forced to cludge our code into just aren't very good. The rash of configuration frameworks was a direct respond to the absurd complexity of the so-called application server.

    As web ans persistence frameworks get better and more mature we'll simply stop needing configuration frameworks.

    -geoff
  58. configuration frameworks? A bad sign.[ Go to top ]

    As web ans persistence frameworks get better and more mature we'll simply stop needing configuration frameworks.

    As soon as enterprise development consists of only integrating with perfectly designed third-party frameworks and legacy systems, we won't need configuration frameworks anymore?

    Sweet! Let me know how that works out. :)
  59. When we need frameworks to configure our code, the real message is that the API's we use to build our apps are too complex. And, the environments we are forced to cludge our code into just aren't very good. The rash of configuration frameworks was a direct respond to the absurd complexity of the so-called application server.As web ans persistence frameworks get better and more mature we'll simply stop needing configuration frameworks.-geoff

    Spring is not a "configuration framework". It's inversion of control. The idea is that the objects get built out side of the dependent objects and inserted into object that need them. Is configuration a part of that? Sure. And Spring simplifies configuration. But that's not the core of what Spring is for - it simply one aspect of it.

    Configuration is something is far too simple to try and build an entire framework around. Especially when when you're running under a container, such as Tomcat, JBoss or Websphere. The configuration can be defined in the container and accessed through JNDI. Here, again, Spring helps simplify our code. If we have an object that's managed by Spring, we need only invoke a setter with the given JNDI value to inject the the value defined in the J2EE container.

    No more constructing of the JNDI context directly in our code. Heck, our code doesn't even have to <em>know</em> it's coming from JNDI. That way if we have to deploy our code to a non-J2EE environment, we need only give it a different Spring context and directly insert the configuration value rather than get it from JNDI (or we can get it from JNDI source - sky's the limit). Again, it's much easier to deploy a different XML file than it is different compiled objects.
  60. CrazyBobis not crazy[ Go to top ]

    I personally did not work with Spring on a real-world project, but I like the ideas such as dependency injection, use of AOP, ability to test POJOs, caching, DAO, etc.

    But if you think about a Java community as a small model of a real world, with a fierce competition, big and small guys, smart people who are trying to invent new things and make the world better, it seems that all these multiple Java frameworks will eventually be swallowed up by one or another J2EE API. Is this a bad thing? I do not think so.
    Java developers like myself can enjoy the never ending stream of new ideas, techniques, technologies, etc. Creators of the frameworks are visionaries, luminaries, and definite leaders of Java community. Spring, Hibernate, iBatis, Abc, Xyz… will always play an important role in Java evolution, but 99% of them will eventually disappear in the melting J2EE pot.

    This was my quick reaction to an interesting blog entry, but I’m planning to give it more thoughts and write a more professional piece on the subject. Let me just grab a Leffe beer from my fridge 
  61. Spring is good[ Go to top ]

    Quick rave, and just my opinion.
    - been using Spring for the last 3 years.
    - dependency injection is much better that JNDI lookups. The Spring config makes complete sense to me.
    - I will stay away from EJBs as far as possible. No, not even EJB3 :) I am not in favor of annotations and prefer centralized configuration and not needing to re-compile.
    - Hibernate works fine for me. I do wish the Hibernate folks would get along better with the Spring folks though : )
    - I use a single database and handle transactions declaratively with Spring AOP
    - Instead of mocks I prefer to test against the database. With the magic of Hibernate and HSQLDB, my ant script creates a fresh database, generates the schema from my hbm file, creates the schema and proceeds to test things like my facade opearations which slice through to the DAO. Very satisfying. I'm now trying to figure out how to use Spring Mocks for testing the MVC stuff also - but hey, there's Selenium... :)
    - As an example of the power of the Spring config is probably the Acegi security project. It had a slightly steep learning curve, but once I "got it" it all made sense because it was all good old Spring config. And it feels good to know that my WAR file will deploy almost anywhere and you don't need to mess with any JAAS config. This is very powerful stuff, true declarative security control over say URLs with wildcards, etc.
    - I'm looking at Spring WebFlow now and am very impressed. Probably the only place where the Spring folks decided to re-invent the wheel is in the MVC stuff. I'm also happy that they appear to be staying away from JSF a little. I'm going to go out on a limb here and say that JSF sucks. Just because it is a Sun standard does not mean that it is the way to go. We saw what happened to Entity beans...

    In short I'm definitely a Spring fan and disagree with Bob. My ideal stack is Acegi - Spring MVC - Spring AOP - Core Spring - Spring Hibernate Template - Hibernate // and Tomcat for the app server. I use HSQLDB for dev and testing. My domain objects and Facade implementation do not import Spring libraries. Everything works great for me and all alternatives to the above stack don't cut it for me. At least for an application with a single JDBC datasource. Now looks like Spring supports POJO MDBs also and optionally exposes objects as JMX components. And theoretically you can plug in a transaction manager like JOTM. Anyone with experience on this :)

    Not looking good for the app server vendors...
  62. WOW ![ Go to top ]

    To quote the movie "Big":

    "What don't you get Josh?"

    What is your alternative? Where's the better solution?
  63. Bob Lee: I Don't Get Spring[ Go to top ]

    Coming soon - "Bitter Spring Framework" at the neighnorhood bookstore near you.

    Quick note from the publisher - Bruce Tate decided not to contribute to this book to avoid appearance of conflict of interest.
  64. So Bob Lee doesn't get it...[ Go to top ]

    ...therefore Bob Lee doesn't have to use it. I can still take advantage of what Spring has to offer to me (which is a lot) and I can continue going on with my life. We're at an age where all people do is complain about silly things. "Too many XML files!", for example. What's wrong with XML files? People are lazy and although there are tools that can make our lives much easier, we will still have to do SOME work. I don't see why xml is such a big deal. There are tradeoffs with just about anything you choose to use these days.

    Anyway, in the world according to Bob, since I love Spring and I use it I must not know what exactly about spring I like. Well I'll tell you.

    1) I like the fact that I can truly program to interfaces without worrying creating tightly coupled factories. This is what I use Dependency Injection for.

    2) I like the fact that I can easily use Hibernate and declarative transaction management without the burden of J2EE.

    3) I like the fact that I can easily weave aspects into my objects that are instantiated via an ApplicationContext or SpringBeanFactory which compliments my loose coupling and programming behind an interface (see #1)

    4) I like the fact that if I choose not to use hibernate for a project, that there are JDBC templates that simplify my code and still allow me to use declarative transaction management.

    I admit there are some things in spring that I may never use. This shouldn't discredit the framework. It's essentially a set of useful, well thought out classes that apply to real world problems aimed at simplifying our code, design, and in the end our lives. If you don't like that, then take the long road, my friend. :)
  65. My respects to Bob Lee.

    In this Spring euphoria, a well-thought-through, critique of Spring, was very much needed. Let's just hope it puts some sense at least into some of those buzz-followers, out there.
  66. Bob Lee: I Don't Get Spring[ Go to top ]

    My respects to Bob Lee.In this Spring euphoria, a well-thought-through, critique of Spring, was very much needed. Let's just hope it puts some sense at least into some of those buzz-followers, out there.

    Which parts of his critique did you find "well thought through"?

    Ilya
  67. Bob Lee: I Don't Get Spring[ Go to top ]

    My respects to Bob Lee.In this Spring euphoria, a well-thought-through, critique of Spring, was very much needed. Let's just hope it puts some sense at least into some of those buzz-followers, out there.
    Which parts of his critique did you find "well thought through"?Ilya
    All of it.
  68. Hani said ......[ Go to top ]

    Look at Hani's “reason” against Spring.

    Hani Suleiman said...
    <quote>
      Damn straight!
      My pet peeve is the whole 'lightweight' nonsense. Take a simple java app, adding Spring to it is in fact a hugely heavyweight proposition. You've just gained 2mb, and your objects are a hell of a lot more expensive to instantiate. Plus all the plumbing you have to gain, and the maintenance thereof makes the prospect unpleasant to say the least.
    </quote>


    This argument is very flawed. Of course, Spring is not good for an app with a handful of classes. The amount of time to set Spring up would be almost the same as to write the app. For departmental level apps, I would go with vb. I am not even going to use Java. See, there is a specific domain that Spring is applied to. Once you have a hammer, everything else looks like a nail. So please think carefully before you start to comment on something.
  69. Hani said ......[ Go to top ]

    Of course, Spring is not good for an app with a handful of classes. The amount of time to set Spring up would be almost the same as to write the app.

    Actually, I would disagree with this, at least in the matter of IoC. My view is that IoC is a good general way to produce clean, maintainable and testable code, and can be applied at all scales of development - even for a handful of classes. After all, you only need a few lines of XML to link them.
  70. Hani said ......[ Go to top ]

    After all, you only need a few lines of XML to link them.

    Or no XML. ;)
  71. Hani said ......[ Go to top ]

    After all, you only need a few lines of XML to link them.
    Or no XML. ;)

    Precisely - I do not think it's difficult to build your own IOC object model (for production and testing) on your own - in fact there is no architecture or framework around it. Most of my classes take interfaces in their constructors. For production code those types are real implementations, for JUnit tests they are fake/mock implementations.

    I don't have one line of XML either, and it's easier to follow than massive amounts of XML spattered around in various files.
  72. Hani said ......[ Go to top ]

    After all, you only need a few lines of XML to link them.
    Or no XML. ;)
    Precisely - I do not think it's difficult to build your own IOC object model (for production and testing) on your own - in fact there is no architecture or framework around it. Most of my classes take interfaces in their constructors. For production code those types are real implementations, for JUnit tests they are fake/mock implementations.I don't have one line of XML either, and it's easier to follow than massive amounts of XML spattered around in various files.

    Nothing is easier or intuitive. If you have a well understood approach and a basic understanding of your tool, it is easy to follow period.

    I have no difficult following our Spring XML files and jumping to them presents no different challenge than jumping to any Java class file I have. And less of a challenge than jumping to a third-party lib for which I have no source.
  73. Hani said ......[ Go to top ]

    Look at Hani's “reason” against Spring. Hani Suleiman said... <quote>&nbsp;&nbsp;Damn straight!&nbsp;&nbsp;My pet peeve is the whole 'lightweight' nonsense. Take a simple java app, adding Spring to it is in fact a hugely heavyweight proposition. You've just gained 2mb, and your objects are a hell of a lot more expensive to instantiate. Plus all the plumbing you have to gain, and the maintenance thereof makes the prospect unpleasant to say the least.</quote>This argument is very flawed. Of course, Spring is not good for an app with a handful of classes. The amount of time to set Spring up would be almost the same as to write the app. For departmental level apps, I would go with vb. I am not even going to use Java. See, there is a specific domain that Spring is applied to. Once you have a hammer, everything else looks like a nail. So please think carefully before you start to comment on something.

    Talk about overuse, that "hammer" analogy is the number one most ill-used analogy since a PC should be like a car!

    People, everyone is not equal. What may be harder for you is not so for me and vice-versa. I had my own proxy code before Spring. I looked at their code, their approach, their roadmap, and decided that what they had was superior to what I had. It was more extensive and more tested.

    It took me one day to port my code and I've never looked back. I have had great success with introducing Spring and Hibernate simultaneously to all the new people ranging from junior to senior and we've had no problems.

    Why?

    Well, one reason there's more material available on Spring than on <fill-in-the-blanks> non-configurable, barely documented framework. Another is that instead of explaining a ThreadLocal to a junior developer who has little experience with threads, they get the benefits. Ditto for transaction support. Instead of seeing code littered with Hibernate session objects, they don't even worry about it.

    I've done 2 and 3 page apps with the same framework as our larger apps and when a new person shows up, they can learn pretty much the architecture for a larger app by looking at the smaller one.

    I'll pass on using 5 different, disjointed approaches when one consistent, scalable approach will do.
  74. Buzz kill on the buzzwords[ Go to top ]

    My respects to Bob Lee.In this Spring euphoria, a well-thought-through, critique of Spring, was very much needed. Let's just hope it puts some sense at least into some of those buzz-followers, out there.

    What buzzwords are you talking about? IoC, DI and AOP????

    IoC and DI are more than buzzwords. Bob Lee wrote one of the first AOP implementation. AOP is more than a buzzword.

    Bob is not against IoC and DI. This is clearly stated in his post.

    What buzzwords are you talking about?

    Did you actually read the post?

    Do you really know where Bob Lee stands on these so called buzzwords?

    Your comment seems ill informed.

    Arrrrrrggggggggghhhhhhhhhh!
  75. Buzz kill on the buzzwords[ Go to top ]

    .Arrrrrrggggggggghhhhhhhhhh!
    Gonna be a sleepless night? :)
  76. Buzz kill on the buzzwords[ Go to top ]

    .Arrrrrrggggggggghhhhhhhhhh!
    Gonna be a sleepless night? :)

    I slept like a baby. Some good wine, and good food did the trick. I am perfecting my own pizza dough recipe.

    I see a lot of general generic statements. I am not sure that Bob would agree with a lot of the people who are "agreeing" with him.

    I'll be interested in what Bob comes up with for IoC. I wouldn't be surprised if he comes up with some improvements.
  77. Buzz kill on the buzzwords[ Go to top ]

    I'll be interested in what Bob comes up with for IoC. I wouldn't be surprised if he comes up with some improvements.

    I'm not sure everyone would see them as improvements. ;)

    If you like plain Java (as opposed to XML) and end-to-end compile time type safety, then we're on the same page. However I get the idea that many developers are fine with and even prefer the XML-based and dynamic approachs even when they're not really needed. Maybe that'll change if/when more developers expect/demand generics. Maybe not.

    I have no plans to release anything at the moment, but if I did, I'd probably work with the Spring folks not against them. Running a successful Open Source project is a *lot* of work. I'm taking the easy way out by throwing some ideas out there and hoping someone picks up a few.
  78. Buzz kill on the buzzwords[ Go to top ]

    I'll be interested in what Bob comes up with for IoC. I wouldn't be surprised if he comes up with some improvements.
    I'm not sure everyone would see them as improvements. ;) If you like plain Java (as opposed to XML) and end-to-end compile time type safety, then we're on the same page. However I get the idea that many developers are fine with and even prefer the XML-based and dynamic approachs even when they're not really needed. Maybe that'll change if/when more developers expect/demand generics. Maybe not.I have no plans to release anything at the moment, but if I did, I'd probably work with the Spring folks not against them. Running a successful Open Source project is a *lot* of work. I'm taking the easy way out by throwing some ideas out there and hoping someone picks up a few.

    That sounds great and i think the Spring folks would welcome that.
  79. Buzz kill on the buzzwords[ Go to top ]

    .Arrrrrrggggggggghhhhhhhhhh!
    Gonna be a sleepless night? :)
    I slept like a baby. Some good wine, and good food did the trick.
    Glad to hear it!
     I am perfecting my own pizza dough recipe.
    Sounds good. When you perfect it I might have to visit Tucson.
  80. Bob Lee: I Don't Get Spring[ Go to top ]

    Bob,

    Thanks for the article, it has enlightened me to a few facts, namely:

    1) Spring has lots of fanboys.
    2) My hesitation to incorporating Spring is justified.

    I still can't think of a reason to use it. Just like you mention in your article, I use the Open Session in View pattern with a ThreadLocal to manage my transactions and I have no problems.

    And yes, I use IOC, specifically Context IOC as documented by Sony Mathew, which you can find in the articles section.
  81. 1) Spring has lots of fanboys.

    That's probably true of almost any well adopted and mostly well liked technology. Its what can takes good technology and turns it into overused technology.
    2) My hesitation to incorporating Spring is justified.I still can't think of a reason to use it.

    Everybody should take this view. Once I learned that Spring helped me understand Dependency Injection and the usefulness of unit tests, I figured out it wasn't about Spring, but about a good design.

    If you haven't found a reason to use Spring... you don't need it.

    But people have gotten into Spring based on the ranting of fanboys and as a result discovered a better way to design, and oh yeah, Spring gave them the tools to help them stitch it together.
  82. Everybody should take this view. Once I learned that Spring helped me understand Dependency Injection and the usefulness of unit tests, I figured out it wasn't about Spring, but about a good design.If you haven't found a reason to use Spring... you don't need it.
    Yes, it is very hard to find a problem if design is without problems ( as less useless stuff like XML for factory with single implementation as better design ).
  83. Bob Lee: I Don't Get Spring[ Go to top ]

    Great! I hope many people don't get it. Namely, the people that we compete with for business. The more people who handle there own persistence, write their own frameworks, use their own factories, etc... the more business we'll win.

    Spring has put money in my pocket and that's more than all the "I don't like Spring/I don't like XML" posts in the world has done for me.
  84. Bob Lee: I Don't Get Spring[ Go to top ]

    Great! I hope many people don't get it. Namely, the people that we compete with for business. The more people who handle there own persistence, write their own frameworks, use their own factories, etc... the more business we'll win.Spring has put money in my pocket and that's more than all the "I don't like Spring/I don't like XML" posts in the world has done for me.

    Now that's the way to go! Them against us, all the way. My framework vs your framework. My country vs your country. Why even bother with open source; putting free time into projects just to help competition out? Nah... ;)
  85. me neither[ Go to top ]

    It is good to hear that i am not the only one. Like others before me said, when you use the parts you need it is OK. But it is often the case that one has to build upon what others build. The others are often gone also. When the others followed the book you are in for something. Interfaces for the sake of it has got nothing to do with good design. I like my f3 not my f4 in eclipse. Everything is an interface because otherwise we cannot proxy the whole thing. Why does everything has to be a proxy in the first place? Hibernate also is cglib all over the place. Effectively making debugging impossible. Now I have this super dooper modulair system that is not all invased by spring, somehow I feel imprissoned though. We are working with 2 on this project and with every piece of spring we take out, the easier our works become. Especially the refactoring is very time consuming with all the dependencies in xml.
  86. Funny coincidence[ Go to top ]

    I recently proposed my co-developers to use an IoC-Container for our redesigned C/S-Application to keep the whole system more manageable/maintainable/testable etc. I mentioned that Spring has all the buzz in this area and asked for some opinions about it (I already had my own).

    A week later one colleague approached me and said: "I read through the whole Spring documentation, I understood the first chapters about BeanFactories etc. but in the end I didn't get it. What is the benefit to have such a mega-framework-wrapper ?". He also tested the Hibernate/iBATIS-Wrappers and wasn't enthusiastic about it (well, they are just wrappers, aren't they ?)

    I was relieved because I had the same experience.

    Afterwards I mentioned HiveMind to the same colleague. Two days later he approached me again, now much more confident, and told me that he likes the IoC technique of HiveMind with its very dedicated functionality and modularity (think about the module descriptors). Not this Uber-Framework that seems to be Spring's mission.

    So, besides Bob there are at least two more people that "don't get it". Perhaps there is a larger group of silent dont-getters who feel ashamed of not being able to embrace the greatness of Spring.
  87. I don't get it either[ Go to top ]

    Those who feel they 'do not get it' may off course benefit from a Core Spring training course.

    Core Spring Training
  88. I don't get it either[ Go to top ]

    Those who feel they 'do not get it' may off course benefit from a Core Spring training course. Core Spring Training

    I don't think training will help what ails them. They seem have philosophical differences.

    I would be the first to say, if you read the Introduction to Spring paper host here and don't see the value, you cannot be convinced.
  89. I don't get it either[ Go to top ]

    For me the problem, from a superficial standpoint, is that Spring seems to be full of contradictions with what I consider good design, starting with their mission statements:

    -- J2EE should be easier to use:
    EJB's are overly complicated, but Servlets and JSP's are about as simple as can be. I find moving your code into XML files and using reflection makes the code more difficult to follow and debug. In addition, having a new set of API's to do stuff that I can already do with the standard Java API's doesn't seem to make things easier. It's just more stuff to learn.

    -- It's best to program to interfaces:
    I agree, but their whole IoC concept seems to bypass interfaces in favor of reflection which means that you just removed the compiler from catching your dependency. Interfaces give you a clear and relatively stable contract to code with, but with reflection that contract with the code is lost. The dependency is still there though. Modify your class or your configuration file and the application won't work or will behave incorrectly. Debugging reflective code in my experience is awful and is a rather fragile way to develop.

    -- OO design is more important than any implementation technology.
    Okay, but this should mean that Spring shouldn't impose a design on me right? But it seems to do just that. It encourages the use of accessor methods, reflective calls, extensive use of configuration files, and a slew of other methodologies related to db access, transaction management, UI, and well pretty much everything.

    -- Testability is essential.
    Which I think implies automated unit testing. Personally I found this *not* to be very true. Often your automated unit tests impose themselves on your design, i.e. I have to modify my code to make it more testable messing up my design, and the unit tests turn out to be just as fallible as the code you are testing. I end up maintaining not just my code but my unit tests as well while still having to do functional tests. If your code is simple, it tends not to be buggy. In my experience however, imposing automated unit tests adds complexity with little benefit. It sounds good on paper but isn't realistic.

    Spring also promotes itself as lightweight, which implies that it has low dependency on your code. However, considering how large and extensive it is, how it promotes a certain way of development, and how much logic resides in the IoC container, I find it hard to believe that there wouldn't be much rework of your code required if you ever decide to not use Spring. To say that Spring has low dependency because you don't have to use everything in it makes no sense to me. If I'm not using it of course I'm not dependent on it. I'm talking about if we do use it.

    I understand that many like Spring and its tools, but it goes against my design sensibilities. I'm coming from the standpoint that the best way to improve your code is through design, not technology. Otherwise, it's just a silver bullet. Design is not technology, but technique, and Spring is technology and lots of it. It doesn't seem to remove complexity, rather it adds to it.

    Furthermore, often I hear people say, "Just don't use it." The problem is that hype is insidious in this industry. It imposes itself on you. Often times you are forced to use a technology against your sensibilities merely on hype. Managers and consultants love hype. I've had nightmarish experiences using EJB, Struts, ORM's, and now .NET. It doesn't help when the proponents of Spring sound very similar to the proponents of EJB's and Struts, which nowadays people seem to loathe.

    Where am I wrong?
  90. I don't get it either[ Go to top ]

    For me the problem, from a superficial standpoint, is that Spring seems to be full of contradictions with what I consider good design, starting with their mission statements:-- J2EE should be easier to use:EJB's are overly complicated, but Servlets and JSP's are about as simple as can be. I find moving your code into XML files and using reflection makes the code more difficult to follow and debug. In addition, having a new set of API's to do stuff that I can already do with the standard Java API's doesn't seem to make things easier. It's just more stuff to learn.-- It's best to program to interfaces:I agree, but their whole IoC concept seems to bypass interfaces in favor of reflection which means that you just removed the compiler from catching your dependency. Interfaces give you a clear and relatively stable contract to code with, but with reflection that contract with the code is lost. The dependency is still there though. Modify your class or your configuration file and the application won't work or will behave incorrectly. Debugging reflective code in my experience is awful and is a rather fragile way to develop.-- OO design is more important than any implementation technology. Okay, but this should mean that Spring shouldn't impose a design on me right? But it seems to do just that. It encourages the use of accessor methods, reflective calls, extensive use of configuration files, and a slew of other methodologies related to db access, transaction management, UI, and well pretty much everything. -- Testability is essential.Which I think implies automated unit testing. Personally I found this *not* to be very true. Often your automated unit tests impose themselves on your design, i.e. I have to modify my code to make it more testable messing up my design, and the unit tests turn out to be just as fallible as the code you are testing. I end up maintaining not just my code but my unit tests as well while still having to do functional tests. If your code is simple, it tends not to be buggy. In my experience however, imposing automated unit tests adds complexity with little benefit. It sounds good on paper but isn't realistic.Spring also promotes itself as lightweight, which implies that it has low dependency on your code. However, considering how large and extensive it is, how it promotes a certain way of development, and how much logic resides in the IoC container, I find it hard to believe that there wouldn't be much rework of your code required if you ever decide to not use Spring. To say that Spring has low dependency because you don't have to use everything in it makes no sense to me. If I'm not using it of course I'm not dependent on it. I'm talking about if we do use it.I understand that many like Spring and its tools, but it goes against my design sensibilities. I'm coming from the standpoint that the best way to improve your code is through design, not technology. Otherwise, it's just a silver bullet. Design is not technology, but technique, and Spring is technology and lots of it. It doesn't seem to remove complexity, rather it adds to it. Furthermore, often I hear people say, "Just don't use it." The problem is that hype is insidious in this industry. It imposes itself on you. Often times you are forced to use a technology against your sensibilities merely on hype. Managers and consultants love hype. I've had nightmarish experiences using EJB, Struts, ORM's, and now .NET. It doesn't help when the proponents of Spring sound very similar to the proponents of EJB's and Struts, which nowadays people seem to loathe.Where am I wrong?

    I wholeheartedly agree with everything you said. I too have suffered through some of these reflection based abominations. It is amazing to me how many projects fail because of these 'frameworks' that are designed to make things simple...simple if you want to read a big fat book on how to use it!

    Furthermore, it's a real problem when you bring new people onto the team. The learning curve is *huge* when you start combining things like struts, ORM, spring, etc. The bottom line is that developers new to a project have to read a big pile of books before they can even start working on the code.

    That sucks, and most of the benefits these frameworks offer can easily be achieved through simply writing good code.
  91. I don't get it either[ Go to top ]

    Fo The bottom line is that developers new to a project have to read a big pile of books before they can even start working on the code.That sucks, and most of the benefits these frameworks offer can easily be achieved through simply writing good code.

    This simply isn't true. We've hired about 5 people in the past 6 months, and I haven't dropped a pile of books on them despite having them utilize our framework consisting of Struts, Spring, and Hibernate.

    First, what is the alternative? Your in-house framework? Been there, done that. Most of this stuff is poorly documented, and the person who started it long gone. At least with Struts, Spring, and Hibernate, you've got a wealth of resources and books and most of the time, the new people DON'T have t ask questions because the answer is in a book. As opposed to chugging bad, inaccurate documentation that is years old at someone, having 6 people write jdbc in 12 different ways(all bad) 8 try-catch blocks per method, no reuse...

    I mean, did you write a substitue for HTML also? Probably not.

    If you use the software correctly, you can actually lessen the curve. I've got a junior guy, right now, modifying one of our apps' search functionality. On the surface, he's uses Struts, Spring, and Hibernate. In reality, he's adding two fields to a scree, adding to attributes to a java bean, and adding three lines of code to a DAO, all without needing to fully understand how Spring works, or how Spring integrates with Hibernate.

    Again, don't blame to tools if the mechanic doesn't know how to use them.
  92. In my defense...[ Go to top ]

    1) I said in the first sentence that I would *only* talk about the dependency injection container, not the AOP, Hibernate, transparent transaction, JDBC template factory, etc. I'm sure other parts besides the DI container are useful, and according to the fans, Spring is so modular that you can use them completely independently of the other parts, right?

    2) I like dependency injection. I love JDK 1.5. I don't like Spring's approach to dependency injection. I'm indifferent to the rest of Spring.

    3) I get Spring. What I don't get is why so many people love Spring so much and look at me like I'm crazy when I don't want to use it for DI.

    4) I'm speaking from the perspective of an API designer, not a user. Thanks for the explanations though.

    5) I would never fault Spring for having too many features (I would fault it for potentially harmful features though). When I talked about the Javadocs being overly complicated, as an API designer, you should provide a clean separation between the interface and implementation. Only expose to the user what they need and what they can depend on. I would actually take it one step further. I'm a big fan of layered APIs. For example, you could have a basic user API and then an extension API for experts. The new java.util.concurrent library demonstrates this approach.

    6) For those of you that only want to read positive articles which validate your decision to use Spring, you can find them on the Spring website. What do you expect from me? I co-authored Bitter EJB after all. ;)

    7) To those of you who think Spring's DI container does more good than bad and actually gives you a competitive advantage over similar applications that simply use DI patterns, what does Springs DI container do for you?

    Bill Poitras gets it:
    I figured out it wasn't about Spring, but about a good design.
  93. In my defense...[ Go to top ]

    1) I said in the first sentence that I would *only* talk about the dependency injection container, not the AOP, Hibernate, transparent transaction, JDBC template factory, etc. I'm sure other parts besides the DI container are useful, and according to the fans, Spring is so modular that you can use them completely independently of the other parts, right?

    Nope, Spring is not that modular. You can not get AOP, Hibernate, transparent transactions unless you are using Spring as the DI container for the affected services. Want the good stuff? You have to marry Spring. Gotcha!

    This sounds like the main disconnect. You are trying to critique Spring DI capability independent of all the supporting services, but to Spring users that doesn't make a whole lot of sense.
  94. In my defense...[ Go to top ]

    Nope, Spring is not that modular. You can not get AOP, Hibernate, transparent transactions unless you are using Spring as the DI container for the affected services.
    That's actually incorrect.

    AOP is quite separate from Spring IoC. Autoproxying requires Spring IoC, but you can use the ProxyFactory API separately. This is also true of the Spring 2.0 AOP enhancements, including the ability to use AspectJ annotation-style aspects.

    All data access functionality (including Hibernate) can be used as a class library without Spring IoC. JdbcTemplate, in particular, is often introduced into existing apps this way. Sure, the classes are designed for convenient use as JavaBeans: but then so are a whole lot of non-Spring APIs such as typical connection pools.

    Transparent transactions: require AOP, not IoC. In Spring 2.0, we provide an AspectJ transaction aspect, for AspectJ users, that has no relationship with Spring IoC.

    While I think the case for using things together is stronger (they are intended as an harmonious whole), the framework really is modular.

    Rgds
    Rod
  95. In my defense...[ Go to top ]

    You can not get AOP, Hibernate, transparent transactions unless you are using Spring as the DI container for the affected services.
    That's actually incorrect.AOP is quite separate from Spring IoC.

    I apologize for being very sloppy in my phrasing. I was incorrect.

    You could use AOP features, including Transaction Management and the HibernateInterceptor outside of the DI framework, but you sure as heck wouldn't want to.

    Spring 2 may very well make a lot of this AOP capability viable as standalone pieces, but I think even Interface21 would agree that currently Spring does not differentiate itself by its standalone AOP functionality.

    The point I was trying to make, and which was much better phrased by yourself and Mr. Vaught, is that the real excitement about Spring, which so befuddles Crazy Bob, is derived by the interaction between Spring's DI and AOP capabilities, not from either piece operating standalone.
  96. A part without the whole[ Go to top ]

    I said in the first sentence that I would *only* talk about the dependency injection container, not the AOP, Hibernate, transparent transaction, JDBC template factory, etc. I'm sure other parts besides the DI container are useful, and according to the fans, Spring is so modular that you can use them completely independently of the other parts, right?

    I don't think that this is the point though is it? It would be quite easy to take a library that offers X features and say "I don't get why people like this library as feature [insert feature] isn't that great and you could just roll your own".

    Sure there are lots of other DI libs out there that can help you. But, if you buy into a lot of the other stuff, then why not use the packaged solution.

    I want to grab an infrastructure and just get on with work.

    Cheers,

    Dion Almaer
    Founder, Ajaxian.com
    http://ajaxian.com
    Cleaning up the web with Ajax
  97. In my defense...[ Go to top ]

    Exactly it's about good design. That's all there is to it right? And DI (Patterns) help to good Design. Basically it boils down to programming against Interfaces, without having to know about the implementing class.
    Well, Spring happens to do DI. Only not quite how you happen to like. Ok.
    Additionally Spring supplies a quite rich set of "Resource" API's, which you may or may not use, but certainly can be very convient "as is" or in combination with the DI.
    But, we are'nt talking about those here.
    You tell us not to use Spring, because of your reservations over how Spring does DI and tell us to simply follow the DI Patterns. Ok, but then again, what was your motivation to write dynaop? I quote from the manual:
    "Using dynaop to make a second class or even all of the classes in a package observable consists of a small configuration tweak rather than hand coding a horde of proxy classes. As with the proxy pattern implementation, dynaop gives you the freedom to use your target class with and without the proxy, or even with multiple different proxy configurations, all at the same time depending on your needs."
    So it really does help to have "something" to "configure" DI . Exactly what Spring does. Maybe not quite "perfect", only i believe the definition of "perfect" is quite up to personal preferences und socio-cultural patterns.
    In a "Enterprise" Computing Enviroment, we don't need "perfect" options, but "valid" options, which give a you certain continuaty, promise you a certain ROI and promise you a evolution path. We all know that software isn't "created", but "maintained". A good path for maintenance is "evolution". I am not a "Spring" fan, i use "Spring" because i have certain requirements, some of which are outlined in the documentation of dynaop manual.
    I have all repects to Bob Lee's Software Engineering knowledge. But i still have to say, that from a "decision making" enterprise computing point of view - i' am just a simple employee - your critic of Spring is simply a "ego trip" - unless you are willing and able to make the "constructive" elements of your critic "mainstream".
    Thanx anyway.
  98. XML and possible runtime errors[ Go to top ]

    The issue I have with Spring is quite similar to the one that I initially had with Struts. The issue was that a single mistyped string in either the XML configuration or the Java source using the XML string couldn't be detected until runtime.

    In Spring, you have to get a bean from the Spring context by using a String and then cast the sucker into the useful object. The error situation can be mitigated by using Enums and the like. But matching the XML to the Enum string can still cause issues. Even if you get the string name right, you can still get ClassCastExceptions by chosing the wrong one and the like.

    In the end these things are chair-keyboard interface issues. But they are quite time consuming. Thankfully, the Struts Eclipse Plug-ins have saved the day with these issues in Struts. But the SpringIDE plug-ins haven't reached that level of maturity.

    That's my complaint with Spring. I hate runtime errors. I look forward to the day that I can find these silly-yet-wasteful issues at compile time and not at runtime.

    John Murray
    Sobetech
  99. XML and possible runtime errors[ Go to top ]

    In Spring, you have to get a bean from the Spring context by using a String and then cast the sucker into the useful object.
    In the vast majority of cases you would use injection rather than explicit lookup. Spring IoC has a number of advanced features to minimize the cases when you need explicit lookup, and the combination of IoC and AOP allows for many requirements for dynamic behaviour to be addressable through injection rather than repeated lookup.

    Before Spring you would have had to do a JNDI lookup (with the naming and casting issue) in many cases, with no injection option.

    Rgds
    Rod
  100. XML and possible runtime errors[ Go to top ]

    The issue I have with Spring is quite similar to the one that I initially had with Struts. The issue was that a single mistyped string in either the XML configuration or the Java source using the XML string couldn't be detected until runtime.In Spring, you have to get a bean from the Spring context by using a String and then cast the sucker into the useful object.

    Your post seems to overstate the range of runtime problems. You might want to qualify what you're saying.

    1. Typically, mistyped string problems can be solved by using a combination of <ref local='xyz'/> and <idref ...> tags.

    2. For our 250+ page, 140+ db table app developed in Spring, we mostly injected object references into other objects and so didn't encounter issues with getting "... a bean from the Spring context by using a String ...".

    3. When you say "runtime", I'd be interested to know if you really mean "startup time" as with a well defined set of Spring config files you can have Spring detect any typos when the application context is loaded.
  101. XML and possible runtime errors[ Go to top ]

    That's my complaint with Spring. I hate runtime errors. I look forward to the day that I can find these silly-yet-wasteful issues at compile time and not at runtime.

    It's a problem that bothered me initially, too. The solution we gradually adopted is actually pretty straightforward - just write simple test cases that load app contexts and assert on things. It's the same issue we need to deal with in every situation where reflection is involved - you just have to write more test cases.
  102. XML and possible runtime errors[ Go to top ]

    I think it doe's not make sence, javac automates this kind of testing without any code, probably XML is just not designed as programming language.
  103. XML and possible runtime errors[ Go to top ]

    I think it doe's not make sence, javac automates this kind of testing without any code, probably XML is just not designed as programming language.

    But this is not a problem coming from XML being used as a programming languaged, which is exactly what I believe Rod Johnson has said in many occasions that Spring is trying to avoid.

    Like I said, whenever you use dynamic typing, e.g., reflection, you have to deal with possible runtime errors. Sufficient test coverage is a good starting point to address this issue.
  104. XML and possible runtime errors[ Go to top ]

    I think it doe's not make sence, javac automates this kind of testing without any code, probably XML is just not designed as programming language.
    But this is not a problem coming from XML being used as a programming languaged, which is exactly what I believe Rod Johnson has said in many occasions that Spring is trying to avoid.Like I said, whenever you use dynamic typing, e.g., reflection, you have to deal with possible runtime errors. Sufficient test coverage is a good starting point to address this issue.
    I do not get it. Why do you need reflection for this kind of code a.k.a DI ?

    MtBean bean = new MyBean();// or BeanFactory.create();

    SessionFactory factory = new Configuration().buildSessionFactory();
    bean.setSessionFactory(factory);


    How reflection framework helps to make this bootstraping better code ?
  105. XML and possible runtime errors[ Go to top ]

    I do not get it. Why do you need reflection for this kind of code a.k.a DI ?

    Please note I said "dynamic typing", with reflection being an example. I wasn't saying reflection had to be used in DI.
    MtBean bean = new MyBean();// or BeanFactory.create();

    SessionFactory factory = new Configuration().buildSessionFactory();
    bean.setSessionFactory(factory);


    How reflection framework helps to make this bootstraping better code ?

    The point here is, how would Configuration figure out which implementation of SessionFactory to create? It would have to be loaded from some sort of configuration file, being it a simple system property, Spring XML, or jdo.properties as shown in another post of your on this thread. So there you have your runtime dynamic loading anyway.
  106. The sum is greater[ Go to top ]

    The value Spring provides is developers of applications is that the sum is far greater than the value of the individual parts.

    Are there better IoC containers? Perhaps, there are certainly lighter weight IoC containers.

    Are there better AOP implementations? There are certainly more complete ones and as acknowledgment of this fact AspectJ is integrated.

    Are there better frameworks for ORM? Spring, for the most part, simply integrates several ORM frameworks providing a consistent interface where possible.

    Are there better frameworks for MVC? There will always be a 'better' one launched next week. Apart from SpringMVC, they integrate several others giving developers a choice of what to use.

    Are there better transaction managers? Spring gives developers a consistent interface across several implementations.

    The real value of Spring is that they have not tried to specialize in any one area. It glues together a variety frameworks in order to provide consistent interfaces for them and make application developers more productive.

    Sure, an application developer could choose their personal favorites in each area and glue them together by hand. But that is not what they are paid to do. Every piece of code not providing business value is just overhead.

    The Spring folks have taken on the unglamorous work of integrating disparate frameworks into a whole that is much greater than the sum of its parts. It is great to see them getting credit. They have made the lives of many application developers less tedious and allowed them to provide more business value for their customers.

    -thom
  107. The point which is Mr. Lee missed, IMO:

    Java is becoming a hybrid programming language = imperative ("how" = Java codes like we know) + descriptive ("what" = annotations, XML decriptions). Combining both gives Java stronger expression.

    BTW. all those descriptions (mostly done in XML) can be easily generated (read: MDA, AndroMDA, cartridge for Spring and EJB). It is worth it to generate them 100% since XML is only a "serialization syntax" and should only handled by tools.

    Cheers,
    Lofi.
  108. My response to Bob Lee[ Go to top ]

    I'd like to start off. I truly feel Bob Lee is brilliant. Call it what you want, but I honestly respect Bob's opinion very much. Anyone who responds to his post with personal attacks about his lack of techncial prowess is misled.

    that said....

    I've been using Spring for 2.5 years, and I enjoy using it.

    Problems stated:
    Many of the complaints you make about Spring are fixed in the 2.0 release. Some of the fixes, I don't agree with, but that is off topic.

    No problem using Spring IoC container:
    I don't see the problem putting course grained objects in the application context file (Spring IoC container if you will).

    First the objects do not have to go in one large file. You can have a file per logical area or divide them up in any way that makes sense.

    Second, objects defined in this file can be decorated with Aspects (even introductions) and add behavior that the client object and the object itself don't know about. This is very extensible. I have used this feature, and it is a real effort saver, and with autoproxies, it can be done very succinctly. How would you do this w/o Spring? Roll your own?

    AspectJ you say. Well okay, but AspectJ has its own pluses and minuses. I'll leave my thoughts on AspectJ for another day. (Bob seemed to has a disdain for AspectJ as well.)

    Third, you can change the implementation you are injecting. For some client frameworks and application this may not be a big deal for others it is. And yes, sometimes you do want to do this. Take Acegi for example, you can use Spring IoC to configure Acegi. You can inject different authentication mechanisms. You can have a development version of Acegi perhaps using mock authentication, and you can also have an integration environment where you use SiteMinder, CAS, etc. (hopefully one day a production env. and don't forget the QA env.). Acegi is very extensible and by simply reading the easy-to-read Spring app context, you can see its extension points. I have used this feature and it is a real effort saver. How do you suggest accomplishing this w/o Spring? Let me guess roll your own.

    Fourth, the Spring application context file is about the easiest thing I know of to read. It is really intuitive. You act as if uses Latin for elements. <etherialize-instantiation> or something. To me, Spring's application context is the very definition of intuitive.

    I feel very strongly that the Spring framework promotes the use of IoC and AOP. Can it be improved? Sure. But, it is the best implementation that I know of. Certainly the most popular as well.

    Spring does promote good practices and it is lighter weight than J2EE.

    I wrote this white paper that is geared toward developers who are learning about Spring IoC and Spring AOP for the first time. In the paper, I state all of the reasons I feel developers should consider using Spring. I will not repeat them here. (Please see http://www.arc-mind.com/whitepapers/SpringIntroduction.pdf).


    Many of the principles and practices in JEE 5 are very similar to what is practiced in Spring. And Spring, is a lot more elegant, evolvable implementation of these principles and practice. If you know of a better framework, let us hear about it.

    This is officially my 2 cents...

    Now I should go back to billable hours or spend some time with the family.

    I've fresh French bread to make.


    --Rick Hightower
  109. My response to Bob Lee[ Go to top ]

    Dion, we're talking about sub frameworks, not features. I'm only interested in DI at the moment anyway. I take something as pervasive as a DI framework very seriously; I don't recommend anyone just pick one and go because you or someone else might end up fixing a lot of code if/when you realize you made a bad choice. I have over a million lines of code checked out at the moment some of which could be 5 years old. I have enough legacy problems to worry about. ;)

    Rick, thanks for the vote of confidence. It means a lot coming from you. I don't think Spring is as evil as I did 24 hours ago. ;) Still not going to use it though. I am interested to see what doors generics can open.
  110. My response to Bob Lee[ Go to top ]

    It means a lot coming from you. I don't think Spring is as evil as I did 24 hours ago. ;) Still not going to use it though. I am interested to see what doors generics can open.

    Well, having in mind that all this started from the DI apsects of Spring ... :-)) Please take a look at Mike Spille's blog, he's one of the most credible/pertinent guys when it comes about programming.

    He's complained some time ago about why he doesn't like Spring, Hivemind and Picocontainer and he still likes DI, and so he's written his own DI framework to use inhouse. It's a pitty he doesn't blog that much anymore, his blog entries were trully deep tech talks in fact.

    BTW, I liked more the automatic bug post in bugzilla blog entry, and that one with building sequence diagrams using AOP which I trully believe is brilliant and I think should replace "logging" as the first use of AOP thus increasing orders of times the rate of AOP credibility/acceptance.

    All in all, please blog more often. At least as often as Cedric. Please ;-).
  111. My response to Bob Lee[ Go to top ]

    Hi Bob
    I am interested to see what doors generics can open.

    I'm interested to hear how you think generics could be used to make a DI container.

    Are you suggesting just writing Java code as your configuration file (DI container) - or have you a cunning plan in mind?

    James
    LogicBlaze
    Open Source SOA
  112. My response to Bob Lee[ Go to top ]

    I'm interested to hear how you think generics could be used to make a DI container. Are you suggesting just writing Java code as your configuration file (DI container) - or have you a cunning plan in mind?JamesLogicBlazeOpen Source SOA

    A little bit of both I think. I started prototyping some ideas yesterday. I'll let you know if anything comes out of it.
  113. My response to Bob Lee[ Go to top ]

    I'm interested to hear how you think generics could be used to make a DI container. Are you suggesting just writing Java code as your configuration file (DI container) - or have you a cunning plan in mind?JamesLogicBlazeOpen Source SOA
    A little bit of both I think. I started prototyping some ideas yesterday. I'll let you know if anything comes out of it.
    Bob, it will be interesting to hear what you come up with.

    Btw, to be slightly more specific on the configuration part of the Spring roadmap that I mentioned earlier in this thread:

    We have an advanced prototype of a Java-based configuration option for Spring, which I've been working on on and off since late summer. The Spring IoC container is flexible enough that it can accommodate even very different configuration styles.

    Configuration is written in Java classes that use annotations containing the necessary metadata. Wiring code is typesafe. There is of course normal Java refactoring support inside configuration files. It differs from other uses of annotations for configuration I've seen in that (among other things) the annotations are in pure configuration, code, rather than in core business code. (Good, rather than bad, as you can use existing objects and they don't need to know about a framework.)

    It can be mixed with existing Spring XML and other configurations, and integrates nicely with Spring AOP (including 2.0 features). The idea is that, as with Spring 2.0 custom configuration, it is an additional option, allowing users to choose the best configuration option for each task. Java code has both positives and negatives for configuration; significant external metadata is absolutely essential in every complex application I've seen, regardless of whether it uses Spring or an ad hoc framework.

    Everyone I've shown this too seems to think that it's a very interesting option.

    Given that we're working flat out on the existing scope of Spring 2.0, we are planning to release this in 2.1--probably around May. (We have more than enough new features for users to absorb, in any case.) After I get back from my well-earned holiday for the rest of this month, I will do enough polishing to allow me to check it into CVS. And it really needs examples and documentation to accompany it.

    If there's enough interest, we might do a preview in March. Could be interesting to discuss in a Spring BOF at TSS, for example.

    Rgds
    Rod
  114. DI + Generics[ Go to top ]

    If anyone would like to get an idea of how generics may be used with dependency injection at compile time checkout ACE (http://www.cs.wustl.edu/~schmidt/ACE.html). This library has been around a long time, is well designed and rocks. Note, it is written in C++ and the dependency injection is called strategy pattern instead.
  115. What's so annoying about Bob's blog is that most part of it is just not constructive, and some even unfounded. Except for that the XML format is Spring-specific, almost all the other concrete claims he made on Spring or Spring team are simply wrong.

    One obvious example is that he claims "The Spring folks openly snub their noses at J2EE," which has been questioned by a few people, including myself in my responding post.

    Another example is that he claims "I have to reference Spring implementation classes in my XML configuration," while there are aboslutely no mandatory references to any Spring implementation classes in the XML file.

    As annoying is the arrogant tone in his entire message. He sounded as if people who happened to decide to adopt Spring, for whatever reason, are all "blind" and brainwashed by "J2EE is bad, and the Spring guys say their stuff is better, so Spring must be good."

    I don't have any problem with people criticizing Spring constructively - it happens everyday on the Spring forums. But simply coming out and bashing it and people who choose to use it before even having got the facts straight? That's just not fair.
  116. I don't have any problem with people criticizing Spring constructively - it happens everyday on the Spring forums. But simply coming out and bashing it and people who choose to use it before even having got the facts straight? That's just not fair.

    I'll try to be less annoying and more constructive the next time. ;)

    For what it's worth, that entry came out of my annoyance from people pushing Spring on me.
  117. Bob Lee: I Don't Get Spring[ Go to top ]

    Spring is real sucks! Too many featchures! Kilometers of xml-configs! Mass uncontrolled setter injection!

    The Pico(http://picocontainer.codehaus.org) is real lightweight and simple solution! Real simple autowire and reliable constructor injection!
  118. Bob Lee: I Don't Get Spring[ Go to top ]

    Probably Pico is better and probably "new MyBeam( new Dependancy() )" is better than
     "bean.setDependancy(new Dependancy())" but I do not need framework and XML for this code.
  119. Bob Lee: I Don't Get Spring[ Go to top ]

    Probably Pico is better and probably "new MyBeam( new Dependancy() )" is better than&nbsp;"bean.setDependancy(new Dependancy())" but I do not need framework and XML for this code.

    How do you do it then? If you wire these things up yourself, you are hard-coding dependencies in your code.
  120. Bob Lee: I Don't Get Spring[ Go to top ]

    Probably Pico is better and probably "new MyBeam( new Dependancy() )" is better than&amp;nbsp;"bean.setDependancy(new Dependancy())" but I do not need framework and XML for this code.
    How do you do it then? If you wire these things up yourself, you are hard-coding dependencies in your code.
    Is it wrong to call setter or constructor in bootstrap code and let compiler to validate it ?
  121. Bob Lee: I Don't Get Spring[ Go to top ]

    Probably Pico is better and probably "new MyBeam( new Dependancy() )" is better than&amp;amp;nbsp;"bean.setDependancy(new Dependancy())" but I do not need framework and XML for this code.
    How do you do it then? If you wire these things up yourself, you are hard-coding dependencies in your code.
    Is it wrong to call setter or constructor in bootstrap code and let compiler to validate it ?

    In my view, yes. You are hard-wiring the class of object you are using in your bootstrap code. This leads to a lack of flexibility and testability. It does not allow others to easily re-use your code with alternative classes or implementations. It does not allow for various useful run-time processing of classes, such as AOP by proxying.

    There is some loss of compile-time checking, but I believe it is worth it.
  122. Bob Lee: I Don't Get Spring[ Go to top ]

    Probably Pico is better and probably "new MyBeam( new Dependancy() )" is better than&amp;amp;amp;nbsp;"bean.setDependancy(new Dependancy())" but I do not need framework and XML for this code.
    How do you do it then? If you wire these things up yourself, you are hard-coding dependencies in your code.
    Is it wrong to call setter or constructor in bootstrap code and let compiler to validate it ?
    In my view, yes. You are hard-wiring the class of object you are using in your bootstrap code. This leads to a lack of flexibility and testability. It does not allow others to easily re-use your code with alternative classes or implementations. It does not allow for various useful run-time processing of classes, such as AOP by proxying.There is some loss of compile-time checking, but I believe it is worth it.
    It is an interesting problem, but I do not have it, OOP helps a lot. Probably I need some framework to provoke this problem.
  123. Bob Lee: I Don't Get Spring[ Go to top ]

    In my view, yes. You are hard-wiring the class of object you are using in your bootstrap code. This leads to a lack of flexibility and testability. It does not allow others to easily re-use your code with alternative classes or implementations. It does not allow for various useful run-time processing of classes, such as AOP by proxying.There is some loss of compile-time checking, but I believe it is worth it.
    It is an interesting problem, but I do not have it, OOP helps a lot. Probably I need some framework to provoke this problem.

    It is not a problem, it is a capability you add to your code. OOP does not help with this, as you can't supply a subclass to your code if the class is already hard-wired into the bootstrap. In fact, you are preventing OOP from helping you by hard-wiring the class.

    It is not a problem provoked by a framework - it is a lack of capability of code without a framework.
  124. Bob Lee: I Don't Get Spring[ Go to top ]

    Probably I get wrong, but It is not an error to use creation design patterns in plain old OOP design.
  125. Bob Lee: I Don't Get Spring[ Go to top ]

    Probably I get wrong, but It is not an error to use creation design patterns in plain old OOP design.

    No it's not but then you have to write a lot of custom factories, singleton, builder, prototypes, ... and the test that goes with it. Your code become more complex and longer. It is a lot of wasted time in my mind.

    Plus, if you want your factories to be able to read an external configuration, you now have to program a custom *xml,bd, whatever* loading solution able to read your project specific format. I have reduced my code by 30% by using IoC.

    Like a lot of people said, a good way to see Spring IoC at first is to think about it as a factory framework.
  126. Bob Lee: I Don't Get Spring[ Go to top ]

    I see no reason to replace comple and long code with complex and long XML, XML just more error prone to bootstrap for programmer and if it pollutes bootstrap with configuration properties then it makes configuration unmaintainable for system administrator.
  127. Bob Lee: I Don't Get Spring[ Go to top ]

    Probably I get wrong, but It is not an error to use creation design patterns in plain old OOP design.

    It is not an error, but it restricts what you can do. With your approach, could someone else easily substitute their own subclass or class matching one of your interfaces without recompiling your code? Could you do this?
  128. Bob Lee: I Don't Get Spring[ Go to top ]

    Probably I get wrong, but It is not an error to use creation design patterns in plain old OOP design.
    It is not an error, but it restricts what you can do. With your approach, could someone else easily substitute their own subclass or class matching one of your interfaces without recompiling your code? Could you do this?
    This bootsrap code doe's not depend on deployment and it is error to change it at runtime. Configuration must be used to configure deployment specific properties like connection URL. I hope Spring is not so broken and separates configuration from bootstrap a.k.a "wiring", does not it ?
  129. Bob Lee: I Don't Get Spring[ Go to top ]

    Configuration must be used to configure deployment specific properties like connection URL. I hope Spring is not so broken and separates configuration from bootstrap a.k.a "wiring", does not it ?
    Of course Spring supports such separation--as I and Rob Harrop have already pointed out in posts in this thread.
  130. Bob Lee: I Don't Get Spring[ Go to top ]

    Probably I get wrong, but It is not an error to use creation design patterns in plain old OOP design.
    It is not an error, but it restricts what you can do. With your approach, could someone else easily substitute their own subclass or class matching one of your interfaces without recompiling your code? Could you do this?
    This bootsrap code doe's not depend on deployment and it is error to change it at runtime. Configuration must be used to configure deployment specific properties like connection URL. I hope Spring is not so broken and separates configuration from bootstrap a.k.a "wiring", does not it ?

    Why should it be an error to change things at runtime? I assume you use JDBC. The driver is usually specified in property or configuration files and loaded at runtime. You surely don't hard code the specific driver class! This gives you freedom to use different classes that conform to the same interface.

    Why shouldn't the specific class you use be a deployment specific property for other situations? IoC allows you to generalise what you do for things like JDBC.
  131. Bob Lee: I Don't Get Spring[ Go to top ]

    Why should it be an error to change things at runtime? I assume you use JDBC. The driver is usually specified in property or configuration files and loaded at runtime. You surely don't hard code the specific driver class! This gives you freedom to use different classes that conform to the same interface. Why shouldn't the specific class you use be a deployment specific property for other situations? IoC allows you to generalise what you do for things like JDBC.
    It looks like you confuse configuration with bootstrap code, I do not suggest to hardcode configuration options.
  132. Bob Lee: I Don't Get Spring[ Go to top ]

    Why should it be an error to change things at runtime? I assume you use JDBC. The driver is usually specified in property or configuration files and loaded at runtime. You surely don't hard code the specific driver class! This gives you freedom to use different classes that conform to the same interface. Why shouldn't the specific class you use be a deployment specific property for other situations? IoC allows you to generalise what you do for things like JDBC.
    It looks like you confuse configuration with bootstrap code, I do not suggest to hardcode configuration options.

    Why is specifying the implementation of java.sql.Driver to be loaded at runtime a 'configuration' option, whereas specifying the implementation (or subclass) of other classes 'bootstrap code'? I can't see the different myself.
  133. Bob Lee: I Don't Get Spring[ Go to top ]

    Why is specifying the implementation of java.sql.Driver to be loaded at runtime a 'configuration' option, whereas specifying the implementation (or subclass) of other classes 'bootstrap code'? I can't see the different myself.
    'bootstrap code' has single correct implementation for all deployments, driver can be replaced (standard way for j2ee applications is to use preconfigured data source). Application or system administrator doe's not need to replace application specific interfaces and domain code (and it is error to replace code if it has single correct implementation), he must see configurable stuff only in configuration file.
  134. Bob Lee: I Don't Get Spring[ Go to top ]

    Application or system administrator doe's not need to replace application specific interfaces and domain code (and it is error to replace code if it has single correct implementation), he must see configurable stuff only in configuration file.

    I think you don't get it. Using IoC doesn't forbid you to construct some objects yourself using the gold old new operator. You don't use IoC to manage your domain objects. You use it when you want to implement a loose relationship with a dependency. For instance, to glue your layers, to use an external library, ...

    Here's a concrete exemple. I had a project wich needed to interact with LDAP and a relationnal BD. Well, hopefully with IoC I can use the same exact interface to do both. Not impossible to do without it but you need to create a factory for every type of persistent object able to read some configuration values. A lot of time wasted because you have to developp your own factory for each type of persistence, your own config file format. Now, if you want to add a type of persistence, you need to recreate a factory for each type of persistent objects.

    Here's a nother case I was happy to use IoC. I had to be able to deploy a security component both localy and remotly using EJB objets because the server wouldn't be ready in time to deploy it. Wich one to use was decided from a config file. IoC helped a lot there, I got ride of a lot of stupid infrstructure classes. Plus, the reading of my config file was already provided by the framework. Basically, I ended up just erasing my now useless factories classes and transforming my PROPIETARY config file in the Spring format. And you should note, that there was no programmation put in my xml file, this programmation is already done in the framework itself.... If you end up with a lot of xml is that you are using IoC at places where you shouldn't.
  135. Bob Lee: I Don't Get Spring[ Go to top ]

    Why is specifying the implementation of java.sql.Driver to be loaded at runtime a 'configuration' option, whereas specifying the implementation (or subclass) of other classes 'bootstrap code'? I can't see the different myself.
    'bootstrap code' has single correct implementation for all deployments, driver can be replaced (standard way for j2ee applications is to use preconfigured data source). Application or system administrator doe's not need to replace application specific interfaces and domain code (and it is error to replace code if it has single correct implementation), he must see configurable stuff only in configuration file.

    I wish I had such confidence that I had a single correct implementation for all deployments. In fact, I don't have any confidence in this at all. I don't even have confidence that an implementation is correct during development: I may wish to replace one of my classes with a Mock version for testing. Why should I have to recompile just do do this?
  136. Bob Lee: I Don't Get Spring[ Go to top ]

    I wish I had such confidence that I had a single correct implementation for all deployments. In fact, I don't have any confidence in this at all. I don't even have confidence that an implementation is correct during development: I may wish to replace one of my classes with a Mock version for testing. Why should I have to recompile just do do this?
     Compiler helps to detect all errors in bootstrap code (it is too trivial code to make semantic mistakes), probably it is possible develop tool for XML too, but I just prefer javac and plain old creation design patterns. If you need some plugin container then probably it doe's not make sence to reinvent it, there are a lot of good and popular implementations like Spring, probably JMX is a good one too. You like standards and components, do not you ? http://java.sun.com/products/JavaManagement.
  137. Bob Lee: I Don't Get Spring[ Go to top ]

    Compiler helps to detect all errors in bootstrap code

    Actually, it doesn't! All the compiler is doing is checking that if you have a particular named class in the classpath at compile time and the right method signatures are there.

    At runtime you could easily substitute an alternative version of the class, which could result in errors.

    You aren't getting the security you think you are.
    (it is too trivial code to make semantic mistakes), probably it is possible develop tool for XML too, but I just prefer javac and plain old creation design patterns.

    Fine, but this is not addressing the issue I raised. How does Javac + such design patterns allow substitution of proxies or mock objects for testing and debugging? Remember - you might not even have the code!
    If you need some plugin container then probably it doe's not make sence to reinvent it, there are a lot of good and popular implementations like Spring, probably JMX is a good one too. You like standards and components, do not you ?

    I do. However, "Java Management Extensions (JMX) technology provides the tools for building distributed, Web-based, modular and dynamic solutions for managing and monitoring devices, applications, and service-driven networks." It is overkill for my needs.
  138. Bob Lee: I Don't Get Spring[ Go to top ]

    How does Javac + such design patterns allow substitution of proxies or mock objects for testing and debugging? Remember - you might not even have the code!
    As I understand Spring helps you to setup mock JDO. Can you demonstrate this magic without code or using "better" DI code than standard way in base class "setUp()" method ?

    protected PersistenceManagerFactory pfm;

    protected void setUp() {
         try{

          Properties properties = new Properties();
          properties.load(getClass().getResourceAsStream("jdo.properties"));
          pmf = JDOHelper.getPersistenceManagerFactory.(properties);

        }catch(Exception e){
           throw new JDOException("setup failed",e);
       }
     }
  139. Bob Lee: I Don't Get Spring[ Go to top ]

    How does Javac + such design patterns allow substitution of proxies or mock objects for testing and debugging? Remember - you might not even have the code!
    As I understand Spring helps you to setup mock JDO. Can you demonstrate this magic without code or using "better" DI code than standard way in base class "setUp()" method ?protected PersistenceManagerFactory pfm;protected void setUp().....

    First of all, you have chosen a bad example to indicate your point. As in the example of JDBC I mentioned earlier, the PersistenceManager implementation loaded dynamically at runtime. It is specified in a Properties, not compiled in. Things can be done better than in your code. You have to load the properties (although it is even easier in JDO 2.0). Doing things your way, you have to get PersistenceManagers in a thread safe way, and you have to explicitly code transactions. I don't know about you, but I don't want to mix thread handling code and transaction code with my tax calculations or my financial report code! It is messy. So, I let Spring so all this for me behind the scenes.
  140. Bob Lee: I Don't Get Spring[ Go to top ]

    Yes I am lame and I am not JDO expert, please demonstrate better code.
  141. Bob Lee: I Don't Get Spring[ Go to top ]

    Yes I am lame and I am not JDO expert, please demonstrate better code.

    There is no code. It is all configuration:

    <bean id="myPmf"
    class="org.springframework.orm.jdo.LocalPersistenceManagerFactoryBean">
        <property name="configLocation" value="classpath:jdo.properties"/>
     </bean>

    Note that this is no more or less dynamic that you loading the PersistenceManagerFactory instance via a properties file in your code, but then you can use Spring JDO classes (JdoTemplate etc.) to provide fully thread-save and transactional code. Neat.
  142. Bob Lee: I Don't Get Spring[ Go to top ]

    Commenting Bob´s Lee blog entry:
    I've noticed what I consider to be a dangerous and blind increase in the rate of Spring adoption.
    I wander his concern about Struts or EJB. So dramatic...
    The Javadocs are unnecessarily overwhelming
    It´s common to complain about the lack of documentation but if you can waste your time complaining about this.. frankly, I bet there MUST be more things to talk about.
    Does all of this really belong in a user API? At least J2EE cleanly separates API from implementation.
    The javadoc just comes with the docs from the source code of all the project, is it bad? It can even inspire you to investigate the implementation framework and contribute.
    the XML configuration is my code, and from what I can see it often ends up constituting a lot of code, all of which is Spring-specific.
    Yes, the XML represents code, configuration code, that to be generic must use the java reflection feature, where you name your object classes, no place better than in a configuration file.
    All your configuration will be in one place, only what you need to care about, the name of the beans and its dependencies, not tedious scaffold repetitive code. And this knowledge about the dependencies between your objects will be consistently reused across your code.
    Why would I want to express all of my dependencies in XML?
    Maybe because your are using a [http://en.wikipedia.org/wiki/Dependency_injection] dependency injection framework and the best way to configure some framework/tool is through configuration files, they all have it, Tomcat, Ant, Apache, Maven, EJB Containers, TestNG, several other Jakarta projects, et cetera. Now with Java 5 we can do a lot of this configuration using [http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html] annotations, like xdoclet have been doing using javadocs, of course, javadoc annotation cannot be read in runtime (just to say one difference, and that´s a big one).
    But there is still a world of configuration that has not this nature of configuring some specific class/method or attribute, like Aspect Oriented programming interceptors. Where would you put that all methods in classes whose name matches the "*Services" expression must be intercepted by some database transactional code?
    Do I use Spring for all of my objects or just the coarse-grained ones?
    Use your own good sense and experience, no framework can make this kind of decision. Do you ask your hammer how much force you will need to use every time you need to fix something?
    I want to validate this stuff at compile time, load time at the latest, not while I'm running my code. Does Spring support that?
    Do you know any Dependency Injection container that does that?
    Doesn't the Spring configuration start to look suspiciously like writing Java code in XML? Is Spring for developers who aren't comfortable with Java? I'm not convinced adding a layer of XML makes things any simpler.
    It´s only configuration code. Oks, we have CMT ([http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Transaction3.html] J2EE docs) where Spring does interfere in your code, using AOP, but not polluting your code, but it´s still there doing lots of work. But it´s your choice to use it, or not.
    Back to dependencies on Spring APIs; don't I have to call the container to create my first object (assuming the rest of the Spring-managed objects in the graph are injected)? I want some way to check that the object I'm requesting is the right type at compile time. I don't want to cast. Ever.
    There is a person who never used a single Java Collections Class (before Java 5), where the classes must be generic so every parameter is a Object (the root class in Java hierarchy). Before Java 5 no java serious application could be written without a Cast, at least from some object that comes from some Collection or Map.
    Do I really even need a container? In Spring you look up objects using a unique ID. I assume most developers define a String constant for the ID in their Java code. That doesn't help me keep the ID value in my java code in sync with the value in my XML. Why do I need both this ID and a container? Why use two objects when one will do? Should we really group all of this information together into a container? Do Java packages and classes not suffice?
    I can´t compare in my mind java packages and classes to any kind of container (from [http://www.picocontainer.org/] Pico to [www.jboss.org] JBoss). I´m sure this one does not need explanation.
    It bothers me that I have to reference Spring implementation classes in my XML configuration. I don't care about the plumbing. In Spring's defense, I've heard they have so more concise, domain-specific XML coming in 2.0, but I haven't seen it yet. Why didn't this come up sooner?
    You may have a point here, spring could work as [http://ant.apache.org] Ant tasks are. But have you ever used Spring? I´ve never bothered about this. Maybe it´s because it's really well documented. And imho, seeing the spring class names in the XML configuration file even makes me fell more in control, more aware of what classes/methods I´m using, I can easily check the source code if I want.
    What's with all the inheritance?
    Most of it are in fact realization of interfaces (only contracts, no coupling with any implementation code).
    And the permutation upon permutation of long winded class names? Not my style.
    Good long and intuitive class names. What does [http://www.springframework.org/docs/api/org/springframework/context/support/ClassPathXmlApplicationContext.html] ClassPathXmlApplicationContext class does? Load from the classpath a XML application context file. My style is to write comprehensive code.
    A good refactoring to the bean creation pipeline would result in easier to follow and more performant code and would enable reuse without resorting to so much inheritance.
    Never heard of performance issues with Spring.
    What's with auto-wiring? Does anyone actually use that, or is just another notch in the feature headboard?
    It works, it´s well [http://static.springframework.org/spring/docs/1.2.x/reference/beans.html#beans-factory-autowire] documented, I use it a lot with my junit test cases (@see TransactionalDAOTestCase).
    How does Spring handle scopes? I heard it will finally support HTTP request and session scopes in version 2.0. I was surprised to here that it didn't support this already.
    Now your talking about Spring MVC.
    Let's not get into the MVC or AOP frameworks. [Un]fortunately I'm not using a dependency injection container at all at the moment.
    I see...
    Fortunately, simply adopting dependency injection design patterns gets you 90% of the way...
    Use Spring and say that again. It really does much more than 10% of the code after adopting dependency injection design patterns.

    Well, I think that´s it.
  143. My reply above is at my blog with more comments in the comments page: http://bpfurtado.livejournal.com/2006/02/01/
  144. Bob Lee: I Don't Get Spring[ Go to top ]

    Yes I am lame and I am not JDO expert, please demonstrate better code.
    There is no code. It is all configuration:<bean id="myPmf"class="org.springframework.orm.jdo.LocalPersistenceManagerFactoryBean">&nbsp;&nbsp;&nbsp;&nbsp;<property name="configLocation" value="classpath:jdo.properties"/>&nbsp;</bean>Note that this is no more or less dynamic that you loading the PersistenceManagerFactory instance via a properties file in your code, but then you can use Spring JDO classes (JdoTemplate etc.) to provide fully thread-save and transactional code. Neat.
    Yes this is magic if there is no code in JUnit "setUp" method. So there is no Spring boostrap code in this method too ?
  145. Bob Lee: I Don't Get Spring[ Go to top ]

    Yes I am lame and I am not JDO expert, please demonstrate better code.
    There is no code. It is all configuration:<bean id="myPmf"class="org.springframework.orm.jdo.LocalPersistenceManagerFactoryBean">&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;<property name="configLocation" value="classpath:jdo.properties"/>&amp;nbsp;</bean>Note that this is no more or less dynamic that you loading the PersistenceManagerFactory instance via a properties file in your code, but then you can use Spring JDO classes (JdoTemplate etc.) to provide fully thread-save and transactional code. Neat.
    Yes this is magic if there is no code in JUnit "setUp" method. So there is no Spring boostrap code in this method too ?

    There is bootstrap code in everything. What matter is how much you have to write.
  146. Bob Lee: I Don't Get Spring[ Go to top ]

    I do not think this stuff is better than my "framework":

    PersistenceManagerFactory pfm = MyFramework.createPersistenceManager("jdo.properties");

    As I understand I must write a lot of code and XML using spring to create persistence manager factory.
  147. Bob Lee: I Don't Get Spring[ Go to top ]

    I do not think this stuff is better than my "framework":PersistenceManagerFactory pfm = MyFramework.createPersistenceManager("jdo.properties");As I understand I must write a lot of code and XML using spring to create persistence manager factory.

    Doing this in spring is no more than two lines of XML, as I have already shown you. And it is better than your code because it is general purpose, handles thread safety and transactions almost all in the background. All you have do there is instanciate one instance of a PersistenceManagerFactory. You have to handle all the rest of these matters manually in your code.

    That is why this Spring stuff is better than your "framework".
  148. Bob Lee: I Don't Get Spring[ Go to top ]

    I do not think this stuff is better than my "framework":PersistenceManagerFactory pfm = MyFramework.createPersistenceManager("jdo.properties");As I understand I must write a lot of code and XML using spring to create persistence manager factory.
    Doing this in spring is no more than two lines of XML, as I have already shown you. And it is better than your code because it is general purpose, handles thread safety and transactions almost all in the background. All you have do there is instanciate one instance of a PersistenceManagerFactory. You have to handle all the rest of these matters manually in your code.That is why this Spring stuff is better than your "framework".
    It sounds like a nonsence, doe's this XML file make my code thread safe ? I hope JDO is not so broken and PMF is thread safe, so my helper helper is thred safe too.
  149. Bob Lee: I Don't Get Spring[ Go to top ]

    Doe's spring uses transactions to load property file to make bootstrap code transactional ?
  150. Bob Lee: I Don't Get Spring[ Go to top ]

    Doe's spring uses transactions to load property file to make bootstrap code transactional ?

    Why would you want to do that? Surely you aren't writing to your properties file at run time? Is this even a serious question?
  151. Bob Lee: I Don't Get Spring[ Go to top ]

    Doe's spring uses transactions to load property file to make bootstrap code transactional ?
    Why would you want to do that? Surely you aren't writing to your properties file at run time? Is this even a serious question?
    I do not want to make DI transactional, but as I understand form you post, DI makes code transactional.
  152. Bob Lee: I Don't Get Spring[ Go to top ]

    Doe's spring uses transactions to load property file to make bootstrap code transactional ?
    Why would you want to do that? Surely you aren't writing to your properties file at run time? Is this even a serious question?
    I do not want to make DI transactional, but as I understand form you post, DI makes code transactional.

    No. It can make some code transactional, with very little effort from the developer. Of course it doesn't make ALL code transactional!
  153. Bob Lee: I Don't Get Spring[ Go to top ]

    It sounds like a nonsence, doe's this XML file make my code thread safe ?

    No, but allowing Spring to create your PMF via such XML configuration is one of the ways to do things which allows Spring to automatically create thread-safe PersistenceManagers.
    I hope JDO is not so broken and PMF is thread safe, so my helper helper is thred safe too.

    If you look at the JDO documentation for most implementations (in fact, the documentation for most ORMs) you will see that it is usually left up to the developer to handle multi-threaded access to their equivalent to PersistenceManagers. You may call this broken, but it has been the way such things have been designed for years. Spring means the developer doesn't have to handle this matter. It helps in this way with the use of JDO, Hibernate, TopLink and iBatis.
  154. Bob Lee: I Don't Get Spring[ Go to top ]

    Doe's it help to set this property http://java.sun.com/products/jdo/javadocs/javax/jdo/PersistenceManagerFactory.html#setMultithreaded(boolean) ?
    Is so complex and you need heavy weight framework to call this method ?
  155. Bob Lee: I Don't Get Spring[ Go to top ]

    Doe's it help to set this property http://java.sun.com/products/jdo/javadocs/javax/jdo/PersistenceManagerFactory.html#setMultithreaded(boolean) ?Is so complex and you need heavy weight framework to call this method ?

    That is an optional feature of a JDO implementation.

    You were showing example code about how you get access to instances of PersistenceManager. This is a separate matter.

    It is far from usual practice to keep persistence managers around for a long time, or to use them for multiple threads. Instead they are created frequently from a single PersistenceManagerFactory. It is access to that PersistenceManagerFactory that needs to be thread-safe.

    I think it might be more helpful if we broadened the discussion up from highly specific details of JDO - you were taking about bootstrap code in general. We can go on talking about ever finer detail of JDO, but I don't think this would be of general interest.
  156. Bob Lee: I Don't Get Spring[ Go to top ]

    Yes multithreading and transactions are not related to DI. DI just builds dependancy graph fom XML, if this graph is very complex then probably it makes sence (similar stuff is used to generate bootstrap code from UML component diagrams), but I think the best way to solve this problem is just to avoid complx dependancy graphs, old plain OOP design and common sence helps to avoid it.
  157. Bob Lee: I Don't Get Spring[ Go to top ]

    Yes multithreading and transactions are not related to DI.

    But they are. Dependency Injection is a good way to allow frameworks to transparently add features to selected classes and instances before they are 'injected' into your selected classes.
    DI just builds dependancy graph fom XML, if this graph is very complex then probably it makes sence (similar stuff is used to generate bootstrap code from UML component diagrams), but I think the best way to solve this problem is just to avoid complx dependancy graphs, old plain OOP design and common sence helps to avoid it.

    I still think you are missing the point. The usefulness of DI is nothing to do with the complexity of the dependencies. It is to do with not having the dependencies no matter how simple or complex hard-coded. If you hard-code dependencies you have the same problem of not being able to substitute alternative classes or implementations (such as mock objects for testing and analysis) without recompilation. This is true whether you have 2 classes or 2,000.
  158. Bob Lee: I Don't Get Spring[ Go to top ]

    I know you weren't responding to me, but...
    But they are. Dependency Injection is a good way to allow frameworks to transparently add features to selected classes and instances before they are 'injected' into your selected classes.

    No. Having a central hook into where you create all of your objects (a factory so to speak or what some like to call a "container") enables you to hook in proxies or decorators which can introduce features. Introduction (to use AOP terminology) and dependency injection are orthogonal.
    I still think you are missing the point. The usefulness of DI is nothing to do with the complexity of the dependencies. It is to do with not having the dependencies no matter how simple or complex hard-coded. If you hard-code dependencies you have the same problem of not being able to substitute alternative classes or implementations (such as mock objects for testing and analysis) without recompilation. This is true whether you have 2 classes or 2,000.

    No again. It has little to do with "hard coding" (whether it's in Java code or XML is an implementation detail) and everything to do with enabling callers to easily provide mock implementations. If you let me pass you a dependency via a setter, I can simply pass you a mock object in my unit test (I don't need to use a container in my unit test obviously).
  159. Bob Lee: I Don't Get Spring[ Go to top ]

    No. Having a central hook into where you create all of your objects (a factory so to speak or what some like to call a "container") enables you to hook in proxies or decorators which can introduce features. Introduction (to use AOP terminology) and dependency injection are orthogonal.

    True, but that does not mean DI is not a useful way to hook things together. Which was my point. My reading of things was that "nothing to do with" was being put forward as some "should never be used with" straw man for later argument.
    No again. It has little to do with "hard coding" (whether it's in Java code or XML is an implementation detail) and everything to do with enabling callers to easily provide mock implementations. If you let me pass you a dependency via a setter, I can simply pass you a mock object in my unit test (I don't need to use a container in my unit test obviously).

    I don't consider whether or not things are in Java code an implementation detail. I see the much of the power of removing dependencies in code being the ability to specify in configuration, rather than code, what those dependencies are.

    I was only giving mock implementations as one small example of how DI can be used. Of course, it can be used without DI.
  160. Bob Lee: I Don't Get Spring[ Go to top ]

    My reading of things was that "nothing to do with" was being put forward as some "should never be used with" straw man for later argument.

    I misquoted. I was referring to the phrase "not related to DI", not "nothing to do with DI".
  161. No. Having a central hook into where you create all of your objects (a factory so to speak or what some like to call a "container") enables you to hook in proxies or decorators which can introduce features. Introduction (to use AOP terminology) and dependency injection are orthogonal.
    True, but that does not mean DI is not a useful way to hook things together.
    Either way loose coupling's the goal. Are containers and aspects technological rivals? Weren't folks claiming that aspects would drive containers almost to the brink of commercial extinction?

    All this chat about plugging, injecting, coupling, and weaving sounds like postmodern programing to me. It's a glue coder's wet dream how comp sci is progressing. Let's cobble together a Frankenstein, built with bricks and mortar.

    Thanks, Mr Lee, for noting the dubiousness of Spring's value prop!
  162. Let's cobble together a Frankenstein, built with bricks and mortar.Thanks, Mr Lee, for noting the dubiousness of Spring's value prop!

    These ideas are not specific to Spring, and it is not about 'cobbling' things together. My view is that software without DI can look like a monster, with unrelated parts bolted together in ways that are hard to change. You can get clean, modular code without DI, but designing with DI in mind helps, I find.

    By the way - Frankenstein was the scientist - the monster was never named!
  163. Bob Lee: I Don't Get Spring[ Go to top ]

    Old plain OOP design solved this problem many years ago (decorators, interceptors). AOP is an interesting way too, but as more I learn it as less good use cases I can find.
    But transaction demarcation is a very bad example for AOP, old plain command design pattern solves this "problem" better. Use case or user action demarcates transaction (or HTTP request in web application), not a method signature, bcouse same method is used for many use cases and I think it is very wrong to demarcate transactions by method signature. It looks like Spring overcomplicates this stuff (EJB overcomplicates it too) It a very is trivial thing and there is no need to fight with transaction demarcation.
  164. Bob Lee: I Don't Get Spring[ Go to top ]

    It a very is trivial thing and there is no need to fight with transaction demarcation.

    I don't know what kind of applications you are building or what you are smoking but transaction is far from being something trivial... Transactions are very important and you can't afford to have made a wrong call or forget one. It's like security, doesn't look to hard to implement but it cross all over the application and so it is very hard to manage but at the same time it has to be easy to change and 100% bullet proof.

    I am glad not having to call the JTA implementation and let the container or Spring AOP do it for me.
  165. Bob Lee: I Don't Get Spring[ Go to top ]

    Yes, transactions are very important and it is very important not make it complex. It is a good idea to learn OOP design (command design pattern) to avoid transaction demarcation frameworks. Learn it and you will find you do not need any springs.
  166. Bob Lee: I Don't Get Spring[ Go to top ]

    Yes, transactions are very important and it is very important not make it complex. It is a good idea to learn OOP design (command design pattern) to avoid transaction demarcation frameworks. Learn it and you will find you do not need any springs.

    I know what is the Command pattern but it is a wasted time to do it this way in my opinion. You add another level of indirection just for Transactions, your code become more bloated in my opinion. A declarative approach is faster and eaiser to use and keeps your code simple. AOP is a good way to adress the shortcoming of OOP.

    I attended a JBoss conference last month and Marc Fleury was predicting the container was going to become just a set of aspects in the future (managed object, pooling, transaction, security, persistence, ...) so you can use whatever you want without having to choose between J2EE, J2SE, J2ME, you use what you need. JPA is already a step in this direction. Sounds great to me!
  167. Bob Lee: I Don't Get Spring[ Go to top ]

    I think transaction demarcation in XML makes it very complex, probably OOP design is is broken, but I do not think XML can fix it.
  168. Bob Lee: I Don't Get Spring[ Go to top ]

    I think transaction demarcation in XML makes it very complex, probably OOP design is is broken, but I do not think XML can fix it.

    Once again you don't have to use XML, DI and AOP are not about XML. It is a particular implementation detail and that what the other of the article didn't like about Spring from what I understand but I much prefer it over implementing my own factories.

    I use annotations to delimit my transactions so you don't need to use xml everywhere...
  169. Bob Lee: I Don't Get Spring[ Go to top ]

    It is better than XML, but I do not think annotations is a good way to demarcate tranasctions too. It is a simple as this reusable pseudo code:

     void execute (Runnable command){
        
         BEGIN;
         try{
            command.run();
         COMMIT;
         }finally{
           ROLLBACK IF ACTIVE;
         }

     }

    Methods called by command do not need any annotations, transactions are demarcated in single place per use case and you can implement deadlock recovery code in single place too. Transaction is an atomic action,same method can be called by many use cases/actions and transaction demarcation per methods just pollutes code and it wrong to demarcate transactions per method by transaction definition. You can implement use case/action as method call to, but it is not so great OOP design (code duplication).
  170. Bob Lee: I Don't Get Spring[ Go to top ]

    There is bootstrap code in everything. What matter is how much you have to write.

    Actually if you use Spring's unit test support classes, you don't have to write any setup code... You just tell it which XML files to load.
  171. Bob Lee: I Don't Get Spring[ Go to top ]

    In my view, yes. You are hard-wiring the class of object you are using in your bootstrap code. This leads to a lack of flexibility and testability. It does not allow others to easily re-use your code with alternative classes or implementations. It does not allow for various useful run-time processing of classes, such as AOP by proxying.There is some loss of compile-time checking, but I believe it is worth it.

    What? What's the difference between "hard wiring" the implementation class in your bootstrap code or XML? The only difference is that you have to recompile (which also means you get compile time checks). If recompiling is a big deal, there's something wrong with your development environment. You get the same level of testability, flexibility, etc. (because hopefully your code is decoupled from the configuration mechanism either way).

    Yes, it may be useful to specify an implementation class without compiling sometimes (like a JDBC driver), but this is the minority of cases. Don't throw away type information for the remaining majority.
  172. Bob Lee: I Don't Get Spring[ Go to top ]

    Spring is real sucks! Too many featchures! Kilometers of xml-configs! Mass uncontrolled setter injection!The Pico(http://picocontainer.codehaus.org) is real lightweight and simple solution! Real simple autowire and reliable constructor injection!

    As an ex-committer I can vouch for Pico; it was probably the first DI container and really pushed the boundaries of IoC / DI containers and is chock full of good ideas; some of which the Spring folks have used.

    Though I still think Spring the best IoC container for general purpose today use as they've gone the extra mile and completed the code, its been stable for a long time and its well documented.

    The biggest difference from an IoC perspective to Pico is that Pico's always had a plethora of options & other containers (Nano etc) for configuring the container which were rarely ever finished completely; with Spring they chose a single simple & stable XML configuration mechanism. Lots of folks want to configure their POJOs in XML which I think is why Spring became the IoC container of choice.

    James
    LogicBlaze
    Open Source SOA
  173. Bob Lee: I Don't Get Spring[ Go to top ]

    Spring is real sucks! Too many featchures! Kilometers of xml-configs! Mass uncontrolled setter injection!The Pico(http://picocontainer.codehaus.org) is real lightweight and simple solution! Real simple autowire and reliable constructor injection!
    As an ex-committer I can vouch for Pico; it was probably the first DI container and really pushed the boundaries of IoC / DI containers and is chock full of good ideas; some of which the Spring folks have used. Though I still think Spring the best IoC container for general purpose today use as they've gone the extra mile and completed the code, its been stable for a long time and its well documented. The biggest difference from an IoC perspective to Pico is that Pico's always had a plethora of options &amp; other containers (Nano etc) for configuring the container which were rarely ever finished completely; with Spring they chose a single simple &amp; stable XML configuration mechanism. Lots of folks want to configure their POJOs in XML which I think is why Spring became the IoC container of choice.JamesLogicBlazeOpen Source SOA


    Spring for many became the framework of choice because it went an extra mile for everything j2ee related.
    You need IoC, you can use spring or something else, but with spring you get extra value in other areas.
    You need AOP you can use something else but with spring you get a lot extra on the table.
    You need an EJB simplifier you can use something else but with spring you get something extra on the table.

    While there are other solutions in the respective areas which might are more extensive spring is an out of the box supportive framework which supports all layers and often you do not have to start to look somewhere else anymore.
  174. Bob Lee: I Don't Get Spring[ Go to top ]

    The biggest difference from an IoC perspective to Pico is that Pico's always had a plethora of options &amp; other containers (Nano etc) for configuring the container which were rarely ever finished completely; with Spring they chose a single simple &amp; stable XML configuration mechanism. Lots of folks want to configure their POJOs in XML which I think is why Spring became the IoC container of choice.

    XML configuration mechanizm is the poorest mechanizm! When projects grows up, support of xml config change to nightmare.
    The main ideas of IoC is autowire and separation between business components and contanier. Spring autowire release poor, if I want use hibernate or another orm I must direved from theirs BlaBlaDaoSupport. Spring discredit general ideas of IoC.
  175. Bob Lee: I Don't Get Spring[ Go to top ]

    Spring autowire release poor, if I want use hibernate or another orm I must direved from theirs BlaBlaDaoSupport.
    I'm not sure whether your post was flamebait or a serious contribution. If it was meant as a serious contribution, I guess it's worth pointing out that it's 100% wrong. And that there's little point in making assertions unless you back them up.

    Spring autowiring support is highly sophisticated. Spring supports autowiring by constructor or through setters using by-type or by-name resolution. There are a variety of dependency checking options. AFAIK Spring's autowire feature set is superior to that of any other IoC container. It's possible to enable autowire at a per-config level if you wish, rather than per-bean. Having said that, however, autowiring is often useful, but far from the "main idea of IoC."
    , if I want use hibernate or another orm I must direved from theirs BlaBlaDaoSupport.
    Wrong, and it would have been trivial for you to check your facts before posting. XXXXSupport classes in Spring are always convenience classes. Given that Java does not allow multiple inheritance, it's particularly important that a framework does not force users to extend a given superclass without good reason. Spring never does. If you want to use any data access library with the accompanying Spring class library, you can trivially construct the relevant Spring helper in code (using a constructor or JavaBean style), or inject it. There is no requirement to extend a Spring superclass.
    Spring discredit general ideas of IoC.
    That's strange, especially as Spring brought the general ideas of IoC to the mainstream.

    Rgds
    Rod
  176. Bob Lee: I Don't Get Spring[ Go to top ]

    XML configuration mechanizm is the poorest mechanizm! When projects grows up, support of xml config change to nightmare.The main ideas of IoC is autowire and separation between business components and contanier. Spring autowire release poor, if I want use hibernate or another orm I must direved from theirs BlaBlaDaoSupport. Spring discredit general ideas of IoC.

    There are two misassumptions I'd like to correct here:

    1. Spring has been fully supporting autowiring in a variety of flavors, and goes very far in fully separating business components from the container. We provide a lot of specific features that allow you to avoid Spring container API imports, such as declarative init/destroy methods, lookup method injection, etc. There is only very rarely a need to implement Spring container callbacks or the like. And if we provide convenience base classes, they are always optional.

    2. DAOs, whether for JDBC or for an ORM, do not have to be derived from our *DaoSupport classes at all. Those are clearly marked as optional convenience classes, essentially just pre-implementing the typical setDataSource / setSessionFactory / etc methods. You can of course have your DAOs coded against plain Hibernate, plain TopLink, even plain JDBC, while still fully participating in Spring's dependency injection and transaction management.

    Besides, JdbcTemplate and even JdbcDaoSupport and co do not constitute container API in the first place. They are effectively library classes that do not have any inherent ties to Spring's core container. They can run very nicely through direct instantiation or in any container that supports setter or constructor injection. And as elaborated above, you can always choose to use the respective resource API (JDBC, Hibernate, TopLink, etc) in its native fashion.

    Juergen
  177. Bob Lee: I Don't Get Spring[ Go to top ]

    XML configuration mechanizm is the poorest mechanizm!
    Highly debatable. XML is a standard representation that has excellent tool support, and many positives to counter its negatives.

    Note also that Spring IoC is most often used with XML configuration, but the IoC container itself has its own Java metadata which is not tied to XML. For example, Spring has always supported the ability to define beans--or values you don't want in XML--in properties file.

    In Spring 2.0 there is a major advance in XML configuration through supporting extensions through importing schema namespaces. This will make many common things more concise, mean fewer angle brackets in general, and be an ideal extension point for the many third party products (like ActiveMQ) that build on Spring. Among other things, it provides a much more focused configuration style for Spring AOP. (As of Spring 2.0, btw, it is also possible to use AspectJ annotation-style syntax, doing sophisticated AOP with zero XML or other configuration.)

    Beyond Spring 2.0, expect vigorous enhancement and innovation in Spring configuration, as in other areas, during the rest of 2006. This will likely include an integrated configuration solution that spans not just XML and properties files and annotations, as at present, but all those things and configuration in Java and scripting languages, configuration in databases and other persistent stores. In the latter case, integration with Spring's JMX export capability should allow cluster-wide safe update in real time.

    Rgds
    Rod
  178. Bob Lee: I Don't Get Spring[ Go to top ]

    As an ex-committer I can vouch for Pico; it was probably the first DI container

    It was quick to arrive. Though when I checked it out years ago, I was very surprised it didn't have dependency cycle checking implemented. Now, isn't that something you want to have implemented before you start shipping a project that is all about dependencies?
  179. Bob Lee: I Don't Get Spring[ Go to top ]

    Actually, James - while Pico certainly was an original project and had interesting design principles, it cannot claim to have been the first DI container.

    The original codebase that became Spring was released in Nov 2002, as download for the book "Expert One-on-One J2EE Design and Development". This code did include full capabilities for what's today called "Setter Injection" already, albeit not under that name yet.

    Even the first official Spring Framework release, 0.9 back in June 2003, came out a couple of days *before* the PicoContainer 1.0 alpha-1 release.

    Pico certainly pioneered Constructor Injection, while Spring certainly pioneered Setter Injection. Spring adopted full Constructor Injection capabilities pretty quickly (in late 2003), while Pico never really properly supported Setter Injection (since that wasn't considered its focus).

    Aside from that, Spring overall always had a much broader focus than Pico or even Pico+Nano. That's well-known, of course, so I don't need to reiterate that.

    Juergen
  180. Thank you Mr. Lee[ Go to top ]

    Well, thanks for making us Spring disbelievers come out. I agree to every word of your post, from the dislike of the xml weak typed configs to JDK 5 generics embracing, to doing IOC simply by yourself... Thanks again.
  181. my 0.5 cents[ Go to top ]

    i have just ported a mid sized web application to spring using only its IoC and service integration (e.g: quartz) features - no AOP yet and no spring web - i use jsf.
    i must say that i managed to throw away a large amount of my infrastructure code using spring.

    i think the problem is that people think spring does some kind of magic - its doesn't.
    the spring guys mainly took already proven concepts and put it under the framework umbrella. thing is, that's what they say they do!! they always said they did nt re-invent the wheel.
     
    buttom line is, from what i have experienced, spring will decrease your TTM drasticly for new projects and will give you a solid 'template' for implementing your business layer.
  182. In my opinion, Spring is the business. It really helps to layer an application properly, and helps guide people to making sound architectural decisions.

    The Spring source code is a delight to read. Well designed code, well javadoc-ed.

    Anyway, on to my point:

    You don't have to use XML for config. The XML is just turned into Java objects at the end of the day, and XML is only one way of doing this. This blog http://www.behindthesite.com/blog/C912632915/E647248081/ describes how to configure a Spring appContext using Groovy, or you could configure it directly in Java if that's what you're into, but the choice *is* yours.

    Regards,

    Mike.
  183. This blog http://www.behindthesite.com/blog/C912632915/E647248081/ describes how to configure a Spring appContext using Groovy, or you could configure it directly in Java if that's what you're into, but the choice *is* yours.Regards,Mike.
    It is coll, but my choice is Creation Design Patterns.
  184. In my opinion, Spring is the business. It really helps to layer an application properly, and helps guide people to making sound architectural decisions.The Spring source code is a delight to read. Well designed code, well javadoc-ed.Anyway, on to my point:You don't have to use XML for config. The XML is just turned into Java objects at the end of the day, and XML is only one way of doing this. This blog http://www.behindthesite.com/blog/C912632915/E647248081/ describes how to configure a Spring appContext using Groovy, or you could configure it directly in Java if that's what you're into, but the choice *is* yours.Regards,Mike.


    I suspect that the people with bad XML experiences didn't really work out a good setup. And use Notepad for an editor!

    With Idea, you can rename classes and it picks up the Spring XML files. Also, I can Ctrl-B directly from an XML file to a class. You can even highlight the class as a hyperlink so you know you didn't mispell. Heck, I get warnings when two ids have the same name. It's getting harder and harder to make even an XML file mistake.

    If support for ref-beans gets upgraded, that will close another hole.

    I think the complaints about the XML config files are over-inflated.
  185. If you don't like xml config don't use it[ Go to top ]

    I think the complaints about the XML config files are over-inflated.

    If I rename a property in my class, does it rename it in my XML? Do I get an error if I specify a property that's not actually in the class (i.e. typo)? Does it verify that the type of a property is compatible?
  186. If you don't like xml config don't use it[ Go to top ]

    I think the complaints about the XML config files are over-inflated.
    If I rename a property in my class, does it rename it in my XML? Do I get an error if I specify a property that's not actually in the class (i.e. typo)? Does it verify that the type of a property is compatible?

    You cut out the section of my post where I SAID that. In Idea, that is what happens.

    And yes, you get an error if you specify a property that doesn't exist. Spring does that at start up

    And yes, you get an error if the type isn't correct correct. Spring does that, too at start up.

    In Idea, If I reference a local bean that doesn't exist, I get alerted to that too.

    But you know what, I rarely get typos because I depend on the tool to help. For example, the copyFQN plugin gives me the fully qualified name that I can paste into XML. For that matter myEclipse has substantial Spring XML file support(Are you listening, Intellij?)

    Over-inflated, as I said. With the exception of your posts, which I don't agree with, the only real complaint I've seen about Spring is about the config files and 9 times out of ten, those people have never used it.
  187. Over-inflated, as I said.

    As *you* said, that is correct. I know at least one person that loaths over-use of XML: me. It seemed that every framework that was introduced the last few years had to introduce it's own XML file (or even multiple files). I know that tool support improved, but it still is harder to refactor/ navigate than Java source files, and I got really tired of having to navigate through multiple files to finally figure out what a given class/ method was actually doing. Furthermore any 'declarative' solution usually provides just a subset of the possibilities a programming language can give you.

    Anyway, it is good to see that there is a focus on less XML lately, and Spring actually helps that with things like annotation support and the fact that it packs together support for multiple frameworks (e.g. Hibernate and Acegi) so that you can do a lot with just the Spring configuration file(s).
  188. XML config - tooling[ Go to top ]

    Hey Bob,

    Have you checked out the Spring IDE Eclipse plugin? Both it and Intelli-J's Spring support are quite cool.

    Basically, for editing bean definitions you get:
    - Auto-complete of bean class names
    - Auto-complete of bean property names
    - Validation (for example, if a property doesn't exist, as you said).

    Now right, if you refactor your component source you *may* have to go update the XML (at least with Spring IDE, IntelliJ may support such coordinated refactorings)--if that's the case and you don't you get a descriptive runtime error. Now perhaps I'm unique here, but I don't mind this. I like treating my "system configuration blueprint" separate from my code--a distinct, externalized concern, one not magically changed because of refactoring that goes on in my source. It's not like we're talking about changes in internal logic affecting these externalized files, either, it's only changes in the external configuration interface, which in my experience, changes less frequently. In addition, with a proper JUnit system configuration test, I get error notification in subsecond speed telling me *exactly* what the problem was in each case, so I know exactly where I need to go to make the change.

    One of the general points about Spring I haven't seen mentioned much is the careful attention placed to error reporting. And Spring IDE rocks! If you're using Spring with Eclipse, use Spring IDE (else use IntellJ :-))

    Keep in mind also since Spring configuration elements are represented in a standard form of metadata, they're also easily engineerable into visual diagrams (like what Spring BeanDoc does).

    Cheers,

    Keith
  189. XML config - tooling[ Go to top ]

    Speaking of which, when can we expect a new release of BeanDoc that doesn't blow up with Spring 2.0 XML? Maybe it could also highlight aspects which are applied to beans?
    Hey Bob,Have you checked out the Spring IDE Eclipse plugin? Both it and Intelli-J's Spring support are quite cool.Basically, for editing bean definitions you get:- Auto-complete of bean class names - Auto-complete of bean property names- Validation (for example, if a property doesn't exist, as you said).Now right, if you refactor your component source you *may* have to go update the XML (at least with Spring IDE, IntelliJ may support such coordinated refactorings)--if that's the case and you don't you get a descriptive runtime error. Now perhaps I'm unique here, but I don't mind this. I like treating my "system configuration blueprint" separate from my code--a distinct, externalized concern, one not magically changed because of refactoring that goes on in my source. It's not like we're talking about changes in internal logic affecting these externalized files, either, it's only changes in the external configuration interface, which in my experience, changes less frequently. In addition, with a proper JUnit system configuration test, I get error notification in subsecond speed telling me *exactly* what the problem was in each case, so I know exactly where I need to go to make the change.One of the general points about Spring I haven't seen mentioned much is the careful attention placed to error reporting. And Spring IDE rocks! If you're using Spring with Eclipse, use Spring IDE (else use IntellJ :-))Keep in mind also since Spring configuration elements are represented in a standard form of metadata, they're also easily engineerable into visual diagrams (like what Spring BeanDoc does).Cheers,Keith
  190. XML config - tooling[ Go to top ]

    Hi,

    Yup, IntelliJ IDEA supports refactoring of property names. Change a setter name, the app context XML gets updated too.

    Regards

    John Hurst
    Wellington, New Zealand
  191. XML config - tooling[ Go to top ]

    Hey Bob,Have you checked out the Spring IDE Eclipse plugin? Both it and Intelli-J's Spring support are quite cool.Basically, for editing bean definitions you get:- Auto-complete of bean class names - Auto-complete of bean property names- Validation (for example, if a property doesn't exist, as you said).Now right, if you refactor your component source you *may* have to go update the XML (at least with Spring IDE, IntelliJ may support such coordinated refactorings)--if that's the case and you don't you get a descriptive runtime error.

    OK, that's good. Does it validate that reference types match up, too? There's no reason it couldn't.

    I also like BeanDoc. That would probably be non-trivial in a pure Java framework.

    Bob
  192. XML config - tooling[ Go to top ]

    OK, that's good. Does it validate that reference types match up, too? There's no reason it couldn't.I also like BeanDoc. That would probably be non-trivial in a pure Java framework.Bob

    Oh, sure... if you hear it in a TSS forum you listen, but if I say it in IM... ;-)
  193. XML config - tooling[ Go to top ]

    Oh, sure... if you hear it in a TSS forum you listen, but if I say it in IM... ;-)

    Hey, I didn't say I was going to use Spring. Defintely not convinced. If you can't roll your own, I guess it's an acceptable alternative though. ;)
  194. XML config - tooling[ Go to top ]

    If you can't roll your own, I guess it's an acceptable alternative though. ;)

    Actually... I would probably just stick to plain old static factories. If you isolate your dependencies on other factories to the factories themselves, you'll have dependency injection. For example, when FooFactory creates a Foo, it will retrieve a Bar from BarFactory and pass the Bar to Foo before returning it.

    This doesn't address circular dependencies and scopes, but that's just a matter of a simple support class for your factories (we're talking a few lines of code).
  195. XML config - tooling[ Go to top ]

    Actually... I would probably just stick to plain old static factories. If you isolate your dependencies on other factories to the factories themselves, you'll have dependency injection. For example, when FooFactory creates a Foo, it will retrieve a Bar from BarFactory and pass the Bar to Foo before returning it. This doesn't address circular dependencies and scopes, but that's just a matter of a simple support class for your factories (we're talking a few lines of code).

    Ok, you go build that. You build a couple dozen unit tests that test different parts of that. See how the statics work for you. Make sure you try running all of your tests individually, then run them all together in one thread using IDEA. Anything fun happen there?

    I can tell you that we're looking to get rid of ALL statics in WebWork that aren't just constants. For instance, the static configuration is a royal pain in the ass, and prevents a lot of nice things you can do with library re-use and app reloading.

    You're just setting yourself up to re-learn the lessons that led to the way Spring works in the first place.
  196. XML config - tooling[ Go to top ]

    Ok, you go build that. You build a couple dozen unit tests that test different parts of that. See how the statics work for you. Make sure you try running all of your tests individually, then run them all together in one thread using IDEA. Anything fun happen there?I can tell you that we're looking to get rid of ALL statics in WebWork that aren't just constants. For instance, the static configuration is a royal pain in the ass, and prevents a lot of nice things you can do with library re-use and app reloading. You're just setting yourself up to re-learn the lessons that led to the way Spring works in the first place.

    No offense, Jason, but as you've already admitted, you're the last person that should be talking to me about statics (I'm comfortable saying that becasue you know statics in WebWork have caused me a lot of pain).

    I fully understand statics and when to use them. In the scheme I'm talking about, there would be no static dependencies in your code. It's nearly identical to the Spring setup except in this case you can actually force dependency injection by layering the factories over your code (i.e. compiling them seperately). It wouldn't even be possible for your code to go directly to the factory unlike in the Spring setup where anyone can pull a bean out of the container.
  197. XML config - tooling[ Go to top ]

    Ok, you go build that. You build a couple dozen unit tests that test different parts of that. See how the statics work for you. Make sure you try running all of your tests individually, then run them all together in one thread using IDEA. Anything fun happen there?I can tell you that we're looking to get rid of ALL statics in WebWork that aren't just constants. For instance, the static configuration is a royal pain in the ass, and prevents a lot of nice things you can do with library re-use and app reloading. You're just setting yourself up to re-learn the lessons that led to the way Spring works in the first place.
    No offense, Jason, but as you've already admitted, you're the last person that should be talking to me about statics (I'm comfortable saying that becasue you know statics in WebWork have caused me a lot of pain).I fully understand statics and when to use them. In the scheme I'm talking about, there would be no static dependencies in your code. It's nearly identical to the Spring setup except in this case you can actually force dependency injection by layering the factories over your code (i.e. compiling them seperately). It wouldn't even be possible for your code to go directly to the factory unlike in the Spring setup where anyone can pull a bean out of the container.

    Aha! I'm the FIRST person to be talking about statics, because I've hurt so many!

    Seriously though, it depends on how you use them. I don't mean to imply that you'd use them foolishly, but statics can be very painful and are hard to clean up after. I personally prefer the approach where you save the registry of beans in a scope which can be reset, such as the way the application context is saved in the application scope of a Servlet app.
  198. XML config - tooling[ Go to top ]

    If you can't roll your own, I guess it's an acceptable alternative though. ;)
    Actually... I would probably just stick to plain old static factories. If you isolate your dependencies on other factories to the factories themselves, you'll have dependency injection. For example, when FooFactory creates a Foo, it will retrieve a Bar from BarFactory and pass the Bar to Foo before returning it. This doesn't address circular dependencies and scopes, but that's just a matter of a simple support class for your factories (we're talking a few lines of code).

    Geez, pass. Multiple factories, but Spring is bad?
  199. XML config - tooling[ Go to top ]

    Geez, pass. Multiple factories, but Spring is bad?

    Multiple factory instances. Do you put all of your domain objects into a heterogeneous untyped map or do you use fields? Why would you do that with your factories then?

    It's as if developers see one solution and get horse blinders to anything else.
  200. XML config - tooling[ Go to top ]

    Geez, pass. Multiple factories, but Spring is bad?
    Multiple factory instances. Do you put all of your domain objects into a heterogeneous untyped map or do you use fields? Why would you do that with your factories then?It's as if developers see one solution and get horse blinders to anything else.

    No, just from what I've read, I don't agree with you. See, that's the problem with blinders, they keep you from seeing the people without blinders.

    If someone comes along with something better than Spring, I'll drop Spring and won't look back. Right, now I just don't think your ideas are that something.

    I see a bunch me "me toos" coming out of the patting themeselves on the back, feeling superior without offering any alternatives besides, guess what? THEIR OWN STUFF!! Your custom factories, your framework, your code.

    Sorry, not thick enough. I was using Spring before the big jump because I was very confident in the techniques. I followed its development for sometime before being satisfied with its soundness and I tried it to convince myself that it worked.

    99% of the me toos who are joining your never used the thing and have to yet actually offer any conherent arguments against it's use besides "I don't like it."

    Again, shrug? I have concrete examples of benefits and we've won real business thanks in part to Spring so all of you "rebels" keep feeling superior writing your own containers.

    When you have something to expose to the light of day, let us all know so the market can decide how good it is.
  201. Factories for IoC ?[ Go to top ]

    Static Factories are not going to be flexible for multiple contexts. Instance Factories will work but the wiring is going to be tedious i.e you'll need factory-interfaces and injection of many factory-impls into objects.

    A simpler approach: when implementing a class X you discover it needs Y - just place getY() into X's Context (inner) interface and forget about it. The pattern is always the same and you never have to think about it. Later, you examine the various Contexts and refactor common signatures into (external) interfaces that represent Factories, Listeners, Adapters, etc and have the Contexts extend these - pure OO at its best. You then provide Impls for these Contexts in different packages or jars i.e. one for test, prod etc. The Context Impls themelves can be designed into big/small/reusable objects using simple OO. Most of all they are compile-time safe and IDE friendly. Ofcourse I'm referring to Context IoC. I see Context IoC and refactoring of Contexts as the root of most common design patterns we use today, i.e. most patterns can be derived by merely refactoring Contexts into super interfaces and impls.

    I've spoken against IoC Containers including Spring - but I see that Spring has a lot of other stuff - i.e. Transactions, Messaging, Hibernate/Dao Support etc. My criticisms of Spring were purely of the IoC Container - and I think Bob is in the same camp. I do see Spring as an alternative to replacing clunky EJBs.

    p.s. why is HighTower's face burried in Lee's behind ?
  202. Bob Lee: I Don't Get Spring[ Go to top ]

    Spring let you worry just about business on your services object, leting hard aspects like resolve other services object to the framework.

    Spring let you configure integration with known good other frameworks and API (Hibernate, iBatis, Log4j, JSTL, Velocity, etc etc etc) simplest. If you don't have Spring you have to read all the doc of each of these framework to configure and use in yours aplication.

    spring.jar is a 2mbytes Full Object Oriented, non-invasive and stateless container with all the funtionality you ever dream inside, ready to use.

    About XML, like hibernate's mapping XML, is easy to read, and can be separated and inhereted, so is very easy to edit and use.

    Spring is a great OO and java code school(just spend a few minutes looking inside spring) , and best of all, Spring recognize weakness and advise about it.

    Thanks Rod Johnson, Jurgen Holler, and all the Spring Team for make so easy to write and to maintain aplication in java, and best, for make one of the best java code school.

    Excuse my English.
  203. Well done Bob ![ Go to top ]

    Congratulations for speaking up Bob. You are not
    the only one who feels like this. I heard a well
    known financial backbone provider are dumping
    Spring for something more lightweight, its too
    bloated and has become the new j2ee elephant.
  204. Well done Bob ![ Go to top ]

    its too
    bloated and has become the new j2ee elephant
    Please define "bloated" if you wish your post to be more than FUD: it's hard to conduct a discussion in such vague terms.

    You use just what you need. Spring's design remains modular, and although it covers more areas now than it did in Spring 1.0, the core remains relatively small. The programming model remains the same; your code does not depend more on Spring than it did in the days of Spring 1.0.

    And please, don't bother arguing based on JAR size. The current Spring JAR size is marginally smaller than the current Hibernate JAR size. Which, given the respective scope of the products, is a pretty good comparison for Spring. Hibernate also depends on more third party JARs to work at all. Spring requires only Commons Logging unless you are using specific integrations. Not that I'm not bashing Hibernate here: JAR size is usually a poor measure anyway. Furthermore, Spring comes with a number of finer-grained JARs if you don't want all of what is in spring.jar anyway. commons-collections.jar is nearly a third of the size of spring.jar.

    Rgds
    Rod
  205. Well done Bob ![ Go to top ]

    Not that I'm not bashing Hibernate here
    Ah, if only it was possible to edit posts on TSS... Should read:

    Note that I'm not bashing Hibernate here
  206. stop bashing hibernate[ Go to top ]

    Stop bashing hibernate
  207. stop bashing hibernate[ Go to top ]

    Rod: Note that I'm not bashing Hibernate here
    Raymond: Stop bashing Hibernate

    Hmmm, how can I be clearer? Especially as it was in bold and italics... :-)
  208. stop bashing hibernate[ Go to top ]

    As I said previously, Spring is the new j2ee elephant
    and this must have struck a chord with you which is
    why you and the rest of the maggots have come out to
    feed.

    If you feel this is wrong, so be it, but there are
    others in the industry who choose to consider other alternatives. Its very simple, so there is no need
    get upset.
  209. you remind me of someone[ Go to top ]

    As I said previously, Spring is the new j2ee elephantand this must have struck a chord with you which iswhy you and the rest of the maggots have come out tofeed. If you feel this is wrong, so be it, but there areothers in the industry who choose to consider other alternatives. Its very simple, so there is no needget upset.

    No meat but just personal attacks and some bit of misinformation?? You kind of remind of someone who Mike Spille once wasted his time trying to reason with.
    What was his the name?? ... I forget ... oh, Arun Patel!!
    Your posts somehow reminds me of him :(
  210. Well done Bob ![ Go to top ]

    its toobloated and has become the new j2ee elephant
    Please define "bloated" if you wish your post to be more than FUD: it's hard to conduct a discussion in such vague terms.You use just what you need. Spring's design remains modular, and although it covers more areas now than it did in Spring 1.0, the core remains relatively small. The programming model remains the same; your code does not depend more on Spring than it did in the days of Spring 1.0.And please, don't bother arguing based on JAR size. The current Spring JAR size is marginally smaller than the current Hibernate JAR size. Which, given the respective scope of the products, is a pretty good comparison for Spring. Hibernate also depends on more third party JARs to work at all. Spring requires only Commons Logging unless you are using specific integrations. Not that I'm not bashing Hibernate here: JAR size is usually a poor measure anyway. Furthermore, Spring comes with a number of finer-grained JARs if you don't want all of what is in spring.jar anyway. commons-collections.jar is nearly a third of the size of spring.jar.RgdsRod

    I frankly think that criticizing a framework mainly intended for use in enterprise apps because of the size of its jar file or the jars that it requires is one of the lamest observations one can do, and I wouldn't lose time replying: if one didn't realize yet that spring is hyper-modular, that its subsystems have been carefully designed to reduce their mutual dependencies and so on, why bother explaining something that won't be accepted anyway? I mean: when people resort to criticize an API with the same observations they would do for an e-mail desktop app (it's "bloated" because it has too many features, it is confusing because it has "too much documentation", it is "heavy" because it has a 2 meg jar file) they IMHO state themselves as unable to grasp that technology at all: is it meaningful trying to convince them?
  211. Don't waste your time, Rod[ Go to top ]

    Rod, don't waste your time responding to these folks that don't appreciate you or Spring. Spend it on people who do appreciate you--family, friends, Spring allies...

    Regardless if it's Bob or ignorant flamers, if they want to hate Spring, let them do so and be proved wrong as the majority of Java developers adopt and use Spring to prevent them from wasting their own time wiring layers, writing ORM base classes, and trying to minimizing dependencies in their code.
  212. Don't waste your time, Rod[ Go to top ]

    Rod, don't waste your time responding to these folks that don't appreciate you or Spring. Spend it on people who do appreciate you--family, friends, Spring allies...Regardless if it's Bob or ignorant flamers, if they want to hate Spring, let them do so and be proved wrong as the majority of Java developers adopt and use Spring to prevent them from wasting their own time wiring layers, writing ORM base classes, and trying to minimizing dependencies in their code.

    I don't think Rod is wasting his time on "these people". Rod is defending Spring from misinformation for those who are considering Spring in the future and has to faces developer x who says "Well Bob Lee says Spring is bad, and I read that IoC and AOP are a bunch of uselesss buzzwords".

    Rod keep up the fine fight.
  213. Don't waste your time, Rod[ Go to top ]

    Rod, don't waste your time responding to these folks that don't appreciate you or Spring. Spend it on people who do appreciate you--family, friends, Spring allies...Regardless if it's Bob or ignorant flamers, if they want to hate Spring, let them do so and be proved wrong as the majority of Java developers adopt and use Spring to prevent them from wasting their own time wiring layers, writing ORM base classes, and trying to minimizing dependencies in their code.
    I don't think Rod is wasting his time on "these people". Rod is defending Spring from misinformation for those who are considering Spring in the future and has to faces developer x who says "Well Bob Lee says Spring is bad, and I read that IoC and AOP are a bunch of uselesss buzzwords".Rod keep up the fine fight.

    Indeed. Know that Spring is helping people not only put food on the table, but enjoy a high quality of life BECAUSE one can put out better software, with less work!

    I don't want to write wiring code(unless I got to contribute to something like Spring). I'd rather spend time with my wife and daughter, read, or just goof-off.

    Spring is helping to make that possible.

    On a side not, I cannot wait until a person I know finishes porting a project using straight Hibernate and custom factories to our Spring-based framework. When I showed here the impact of using the Spring-Hibernate convinience classes alone, here eyes popped.
  214. Don't waste your time, Rod[ Go to top ]

    Know that Spring is helping people not only put food on the table, but enjoy a high quality of life BECAUSE one can put out better software, with less work!

    Customers bring food on da table not spring, quality of life is exactly what is degrading in proxy universe. Better software with less work, give me a big break. Good design does force everything to be a proxy. The whole proxy thing is a bad dream. A nightare. It pisses me off that we as a community of bright people cannot come with something simple, it has to be compicated, always complicated.
  215. Don't waste your time, Rod[ Go to top ]

    Know that Spring is helping people not only put food on the table, but enjoy a high quality of life BECAUSE one can put out better software, with less work!
    Customers bring food on da table not spring, quality of life is exactly what is degrading in proxy universe. Better software with less work, give me a big break. Good design does force everything to be a proxy. The whole proxy thing is a bad dream. A nightare. It pisses me off that we as a community of bright people cannot come with something simple, it has to be compicated, always complicated.

    First, I said helping. If you are going to comment, try reading what I wrote first. Second, I don't care what you think about what I wrote. Spring has affected my bottem line far more than you.

    If Spring is too complicated for you, don't use it.
  216. Don't waste your time, Rod[ Go to top ]

    I am just fed up with frameworks. I still like to program but work is just not fun anymore and I am pissed about that, especially at the end of the day. Interfaces are great and dynamic proxies also but not all the time everywhere. I really looked forward to the current project i am working on since it was going to be my first spring job. I was dissapointed from day one. Bob is really courages to stand up against it. I wouldn't dare to start it but i am with him.
  217. Don't waste your time, Rod[ Go to top ]

    Interfaces are great and dynamic proxies also but not all the time everywhere.

    Note that Spring neither forces your business services to implement interfaces not to have dynamic proxies for them.

    Spring's core container works perfectly well with plain target classes. While implementing business interfaces is considered a best practice, it is by no means required.

    Proxies are only created for objects that you actually configured a proxy for. Spring will not create proxies unless told to do so, whether through a ProxyFactoryBean or an auto-proxy creator.

    The main reason to create proxies is applying AOP interceptors, of course, for example for declarative transactions. This is only applied selectively to the target objects that you chose, though.

    Juergen
  218. Don't waste your time, Rod[ Go to top ]

    Interfaces are great and dynamic proxies also but not all the time everywhere.
    Note that Spring neither forces your business services to implement interfaces not to have dynamic proxies for them. Spring's core container works perfectly well with plain target classes. While implementing business interfaces is considered a best practice, it is by no means required.Proxies are only created for objects that you actually configured a proxy for. Spring will not create proxies unless told to do so, whether through a ProxyFactoryBean or an auto-proxy creator.The main reason to create proxies is applying AOP interceptors, of course, for example for declarative transactions. This is only applied selectively to the target objects that you chose, though.Juergen

    Thanks for your effort to convince me, i appreciate that. If i dont apply aop and i like to work with the good old locator pattern then what has spring to offer for me I wonder? I agree with you that business interfaces are good practice. I am in the situation where the domain classes, the dao's and the managers are interfaces. When I look up something it is always manager.getThing calls dao.getThing gives back interfaces wich are proxies. The managers can be interfaces when needed but the rest is too much i think. What is your opinion about that?
  219. Don't waste your time, Rod[ Go to top ]

    Interfaces are great and dynamic proxies also but not all the time everywhere.
    Note that Spring neither forces your business services to implement interfaces not to have dynamic proxies for them. Spring's core container works perfectly well with plain target classes. While implementing business interfaces is considered a best practice, it is by no means required.Proxies are only created for objects that you actually configured a proxy for. Spring will not create proxies unless told to do so, whether through a ProxyFactoryBean or an auto-proxy creator.The main reason to create proxies is applying AOP interceptors, of course, for example for declarative transactions. This is only applied selectively to the target objects that you chose, though.Juergen
    Thanks for your effort to convince me, i appreciate that. If i dont apply aop and i like to work with the good old locator pattern then what has spring to offer for me I wonder? I agree with you that business interfaces are good practice. I am in the situation where the domain classes, the dao's and the managers are interfaces. When I look up something it is always manager.getThing calls dao.getThing gives back interfaces wich are proxies. The managers can be interfaces when needed but the rest is too much i think. What is your opinion about that?

    Again, this is an implementation issue. Why do people insist on blaming an entire class of technology based on how some people use it.

    100% of all car accidents are caused by the users of cars, but I don't hear any complaints about cars being overdone, or is a bad technology.

    Do you ask Ford that their opinion of speeders or drunk drivers is?
  220. Don't waste your time, Rod[ Go to top ]

    Do you ask Ford that their opinion of speeders or drunk drivers is?

    So you also agree with me that having the managers and the dao's and the domain classes as interfaces can be compared to drunk driving. I am actually really intersted if the spring people set up their systems like this. I think it is wrong unless somebody explains me why it is right and I can agree with that.
  221. Don't waste your time, Rod[ Go to top ]

    Do you ask Ford that their opinion of speeders or drunk drivers is?
    So you also agree with me that having the managers and the dao's and the domain classes as interfaces can be compared to drunk driving. I am actually really intersted if the spring people set up their systems like this. I think it is wrong unless somebody explains me why it is right and I can agree with that.

    What I am saying is that you should condemn a tool because someone you worked with uses it badly. I don't believe domain objects need to be interfaces, but I do believe that DAOs should be.

    And this has nothing to do with Spring. This has everything to do with how I write code. I also supply Abstract Implemenations for all my Interfaces. Again, nothing with Spring, but instead a jewel I picked up out of Effective Java.
  222. Well done Bob ![ Go to top ]

    Congratulations for speaking up Bob. You are notthe only one who feels like this. I heard a wellknown financial backbone provider are dumpingSpring for something more lightweight, its toobloated and has become the new j2ee elephant.

    What did they choose? I'm curious.
  223. Bob Lee: I Don't Get Spring[ Go to top ]

    Everytime a framework gains in popularity, there is someone quick to tear it down. A'la Struts backlash. AJAX backlash. Now, even Spring backlash.

    Not saying that we shouldnt improve our processes - just give them some time to work it out, before turning on them like rabid dogs.
  224. Bob Lee: I Don't Get Spring[ Go to top ]

    Everytime a framework gains in popularity, there is someone quick to tear it down. A'la Struts backlash. AJAX backlash. Now, even Spring backlash.Not saying that we shouldnt improve our processes - just give them some time to work it out, before turning on them like rabid dogs.

    Actually Struts has a number of problems (most of them being addressed by JSF and other new frameworks)

    Ajax, this stuff is simply broken by design due to the fact that javascript does not have any constructs for multitasking and yet with asynchronous xmlhttp you run into exact those situations were critical regions semaphores etc... are needed.

    ;-)
    Just to tear the stuff down quickly
  225. Bob Lee: I Don't Get Spring[ Go to top ]

    Everytime a framework gains in popularity, there is someone quick to tear it down. A'la Struts backlash. AJAX backlash. Now, even Spring backlash.Not saying that we shouldnt improve our processes - just give them some time to work it out, before turning on them like rabid dogs.
    Actually Struts has a number of problems (most of them being addressed by JSF and other new frameworks)
    JSF does not address Struts problems, it addresses its own problems.
    Ajax, this stuff is simply broken by design due to the fact that javascript does not have any constructs for multitasking and yet with asynchronous xmlhttp you run into exact those situations were critical regions semaphores etc... are needed. ;-) Just to tear the stuff down quickly
    It is possible to fire up several XHR simultaneously and to process the response in different threads. I still yet to find how to make these requests in strict order, Javascript does not have wait(), that is true. Afaik, all it allows is to call a certain method after a timeout.

    ---
    Michael Jouravlev
    JSP Controls: Create page components with JSP
  226. Hi there,

    We've been using Spring for about a year, and we like it. We have four production applications that use it, and we're beginning to incorporate it into our legacy apps as we do maintenance on them.

    Our individual applications use common service, persistence, and utility packages. The only issue we've really had with spring is properly partitioning all the xml context files in all the layers so a given application is properly configured.

    Other than that, it's been quite useful. I hate to say it, because it'll probably provoke someone and I'm not trying to troll, but spring has actually served as a stepping stone to Seam.


    Patrick
    --
  227. My detailed defence of Spring based on this arguments are here: http://bpfurtado.livejournal.com/19570.html
  228. Bob Lee: I Don't Get Spring[ Go to top ]

    Why do people use a lot of things?? Why not just use Embedded SQL with C++? Why use Java? Why use J2EE?

    Frankly I think people are just looking to get their job done more efficiently. Why write a bunch of yada, yada code when Spring gives me templates, IoC, AOP, transactions, JMS messaging templates, JAX-RPC, MVC...I mean really, how can you not get Spring?

    I'm tired of doing the same old, same old and if there's a framework to handle the mundane then great! If there's a friendly community and great docs, articles, books, etc. to support -- then even more power to it AND less FUD from the pointy hair boss.

    Moreover, if there's momementum behind this Spring thing, then I can hire others that know it without having to teach them my whoop-de-do framework. As an architect, that's a very compelling reason! Kind of the whole point of J2EE in the first place that it blundered on the go around but now seems to be getting it.

    Spring makes life simplier especially running on tight deadlines. Simple is good...

    Lou

    p.s. Spring IDE (eclipse plug-in) makes the applicationContext.xml manageable.
  229. Bob Lee: I Don't Get Spring[ Go to top ]

    Why do people use a lot of things?? Why not just use Embedded SQL with C++? Why use Java? Why use J2EE?Frankly I think people are just looking to get their job done more efficiently. Why write a bunch of yada, yada code when Spring gives me templates, IoC, AOP, transactions, JMS messaging templates, JAX-RPC, MVC...I mean really, how can you not get Spring? I'm tired of doing the same old, same old and if there's a framework to handle the mundane then great! If there's a friendly community and great docs, articles, books, etc. to support -- then even more power to it AND less FUD from the pointy hair boss. Moreover, if there's momementum behind this Spring thing, then I can hire others that know it without having to teach them my whoop-de-do framework. As an architect, that's a very compelling reason! Kind of the whole point of J2EE in the first place that it blundered on the go around but now seems to be getting it.Spring makes life simplier especially running on tight deadlines. Simple is good...Loup.s. Spring IDE (eclipse plug-in) makes the applicationContext.xml manageable.

    +1
    leverage,leverage and leverage !!!
  230. Can u fell that ?[ Go to top ]

    Humm, I noticed the fact Bob had mention Ruby 3 times in the article. I guess I know what he means. Some of my project pairs just seems not interested to learn all that "cool" things like Spring, Hibernate, Tapestry, JUnit, <
    I think it´s ok. Actually it´s a "Homer Simpson" way of life but I can totally understand that they work just to pay their way of life with their wifes, kids and hobbies and not actually because they want to learn and play the last cool thing every 2 or even 1 year like nowadays. What a hell, they are right !

    So i´ve stoped to push that "cool" stuff within the projects I work for. I decided I will follow the skill set they want from me (even if it sounds useless or sometimes ridiculous for me) and that´s it. I didn´t need to like the approach but its the way I pay my rental.

    But to not loose 100% of my "programmer mojo", I decided I will start playing with my own stack. So I spent the last 2 weeks playing with

    http://click.sourceforge.net

    and in fact I even was able to integrate it with Jython so now I can write a web application with 1 really simple and small configuration xml file and 1 .py file with all my pages inside it. Click is a "component based" web framework like Tapestry or Wicket but _much_ more simpler to learn and play. No, it doesn´t have any killer feature like automatic state management or 100% custom markup free in your html (it uses Velocity) but I guess any average Java programmer can easily understand their source code, a not viable thing with all others frameworks i have been seen so far.

    I am still getting confidence in my small implementation (actually a simple hack of PyServlet and a less than 12 lines of code within a Click class) but will introduce it to Click guys soon. After this I will try to put http://pbeans.sourceforge.net to work within my stack. So far I have not missing dependency injection or AOP I guess because Jython is very dynamic. Nor I do care about scalability (although Click is amazing fast and for persistence there are some good transactional and clusterized Maps implementations around...) right now.

    My goal is to have a toolkit witch really empower me _and_ my project peers ! I want to be agile like that err, that R.R. guys but I want to stay with Java because I guess the money is there ;-)

    And to be honest, I do not believe anymore Spring, Hibernate, etc allow me or my team to express a application so fast like these Ruby guys have been talking about. We are talking about humans, anyway. For those who would probally call me a code monkey, well, i am. You probally spent some
    years doing business applications with C++ and statically compiled SQL code but at the same time I was doing dozens of projects with FoxPro/Netware stack and well, the business value return was great.

    The only missing thing was actually the "enterprise" grade status but now I am Java programmer and I know how to customize a design to fix this easily...I know how to use a Map ;-) And I am sure that some projects could be a success by using just "agile light tools" like these some of us are dreaming about, without any need of the "enterprise grade" label.
  231. Correction of my first phrase[ Go to top ]

    Humm, I noticed the fact Bob had mention Ruby 3 times in the article. I guess I know what he means. Some of my project pairs just seems not interested to learn all that "cool" things like Spring, Hibernate, Tapestry, JUnit, plug your own and sometimes, even a dead horse like Struts.
  232. Spring is modular?[ Go to top ]

    For those who love Spring being modular. Here's a question:

    Why do I have to use Spring to use Acegi?
    Why do I have to use Spring DI container to use Spring MVC?


    Spring's aop framework is an exceptional modular design in the sense that it has no dependency on the container. One can always embed it into code not using Spring appcontext at all. I'd say at least 50% of Spring's success should be attributed to Spring aop framework, most notably, the declarative transaction interceptor.

    But, Spring is designed in a dangerous way that any extension can easily lead to strong coupling with the infrastructure. (Hm, might be a good marketing strategy, just so people can have less choice other than using Spring)

    Watch out to those _aware_ interfaces. The designer seems to
    take them too easy like "Ok, there's this new problem to tackle, just drop in another NewProblemAware marker interface. who cares?".

    But such marker interfaces make Spring very hard to be embedded. The embedder is forced to do lots of "instanceof" for them. And still worry about more marker interfaces being introduced in future Spring version.

    If ever spring's light-weightness is questionable, they are the culprits.


    Armed with these dubious _aware_ interfaces, Spring's extensibility is still limited. Take the Spring2's solution for anemic domain model. After using aspectj, ApplicationContextAware, annotation, one still has to end up with either an implicit contrace between xml and code or a "bean name" in the source code. Shouldn't I just forget about infrastructure and be free in designing my pojo?

    By the way, Spring's performance on prototype beans are _slowwwww_. This link is a simple benchmark summarizing bean creation performance:
    http://docs.codehaus.org/display/YAN/Performance+Test+%28Nuts+vs+Spring%29


    Overall, Spring makes a nice aop solution, a pracical integration of lots of useful technologies into one shop, kinda like developers' Warlmart. But technically, the DI framework is not great.
  233. Spring is modular?[ Go to top ]

    Ben
    Why do I have to use Spring DI container to use Spring MVC?
    It's sound engineering practice for higher level components to build on an underlying base. Adding an abstraction layer under Spring MVC would have been possible, but it's hard to see the motivation, especially as the MVC framework was part of the project from the beginning, along with the IoC container. Moreover, such an abstraction would probably have added complexity to maintenance and possibly user experience. If Spring IoC depended on Spring MVC, that would be bad; no one (except you) has ever objected to the reverse AFAIK. In any case, if you wanted to use Spring MVC with another IoC container, it would be quite possible to integrate it, using Spring IoC only for the web-tier artefacts itself.
    But, Spring is designed in a dangerous way that any extension can easily lead to strong coupling with the infrastructure. (Hm, might be a good marketing strategy, just so people can have less choice other than using Spring)
    I disagree (see below). While we're on the subject of marketing, you failed to mention fact that you are the lead of another IoC container, so are hardly impartial. Of course the same can be said of me--although Spring actually grew out of my previous writing and consulting work, so my fundamental technical views came first. Which is why it's best to debate on technical detail, rather than refer to products being "dangerous".
    Watch out to those _aware_ interfaces. The designer seems to
    take them too easy like "Ok, there's this new problem to tackle, just drop in another NewProblemAware marker interface. who cares?".
    Spring documentation and the many books on Spring are clear about the fact that using Aware interfaces, as with explicit dependencies on the IoC container, is not recommended in typical user code. Nor is it necessary. Spring goes a long way to help dependence on the container, using features such as lookup methods. I've been involved in or reviewed dozens of Spring applications, and a very small proportion of classes need to use Spring IoC container APIs.

    When code is actually extending a framework, rather than designed to run within it, there is no particular reason to hide framework APIs. So if I write a business app to run on Spring, I don't want to see Spring configuration APIs (and very seldom do); if I write a framework that extends Spring (or any other framework) I'm quite happy to get down to the metal. Users extending frameworks expect the ability to access framework-level infrastructure. It's the framework's responsibility to enable a clear division between infrastructure extension code and application code, and Spring does that.

    As for "just drop in another NewProblemAware marker interface. who cares?": We believe that we have chosen a responsible path with API design with Spring. IMO the fact that it was possible to make Spring 2.0 backward compatible, despite the major enhancements it contains, is proof that we are doing rather well. We simply do not adopt the irresponsible attitude you imply, and Spring would not be where it is today if we did.
    Armed with these dubious _aware_ interfaces, Spring's extensibility is still limited.
    A large and growing number of prominent projects and products build on Spring (ActiveMQ, Jetspeed, Alfresco CMS etc), not to mention numerous sophisticated in-house frameworks. Spring's popularity owes much to the fact that it is very easy to extend compared to most frameworks. Furthermore, Spring offers many extension points other than the Aware interfaces, such as bean post processors, which provide the ability to externalize Spring-dependent logic from managed classes.
    Take the Spring2's solution for anemic domain model. After using aspectj, ApplicationContextAware, annotation, one still has to end up with either an implicit contrace between xml and code or a "bean name" in the source code. Shouldn't I just forget about infrastructure and be free in designing my pojo?
    This is simply wrong. The ApplicationContextAware interface is nothing to do with this, and is not required. It's possible to apply DI to any object with Spring 2 without using an annotation. The annotation is optional, and if you consider typical use cases, not going to be required very often.

    Rgds
    Rod
  234. Spring is modular?[ Go to top ]

    It's sound engineering practice for higher level components to build on an underlying base. Adding an abstraction layer under Spring MVC would have been possible, but it's hard to see the motivation, especially as the MVC framework was part of the project from the beginning, along with the IoC container.

    Yes. I can see that mvc was designed on top of spring ioc from day 1. So trying to use it outside of spring ioc was probably never in the project scope.

    But that doesn't mean that the mvc framework should definitely be coupled with a container. It was designed so and works when one doesn't care about the coupling. That's all.

    It might be practical, but not "modular". "modular" means to me some independent chips that can be plugged and switched on and off a motherboard, not a super motherboard with everything fused together.

    Is it gonna be harder to design it in a container-independent way? I'm not sure. The mvc and ioc container just look quite orthogonal to me. Imho, mvc can take advantage of the di container configuration, but the core should not have required a specific container to run.



    > you failed to mention fact that you are the lead of another IoC container, so are hardly impartial

    Being someone who write container doesn't automatically make me partial. I might be subjective, as everyone is, but I'm trying to be impartial as far as I know.

    I used the word "dangerous" because whenever I sit down to look into a piece of code that integrates with Spring, very rarely that I don't see these _aware_ interfaces (or bean post processors, whatever). People tend to use them as a sanctioned way of extending or integrating Spring. And I used "acegi" and spring mvc to show that it happens with even very prestigous software.


    > if I write a framework that extends Spring (or any other framework) I'm quite happy to get down to the metal.

    I guess that's the rationale behind acegi and spring mvc being so tightly coupled with a certain container. Different from you, I'm not happy with two pieces of interwined metal that should have been independent of each other. Security, mvc, ioc container are all metal infrastructures, but that doesn't mean they should be interwined.


    > Spring's popularity owes much to the fact that it is very easy to extend compared to most frameworks.

    "very" is a word as subjective as "limited". Take the anemic model solution as example, how do you extend Spring so that "who gets injected", "which bean is used to inject which component" kind of logic can all be centrally configured within Spring without explicit or implicit bidirectional coupling between config file and pojo?

    I know you can avoid the bean name and annotation if the property name and the bean name follow some predefined pattern, but that's just an implicit coupling.
    Traditionally, spring config files depend on pojo, but pojo doesn't depend back in any way. It's sad to see that elegance going away.

    Rgds,

    Ben.
  235. Spring 2.0 anemic domain model solution[ Go to top ]

    Ben
    Spring's popularity owes much to the fact that it is very easy to extend compared to most frameworks.
    "very" is a word as subjective as "limited".
    My comment--that Spring was easy to extent--was not subjective. I cited some of the many frameworks that extend Spring in a wide variety of ways. It's not just my opinion.
    Take the anemic model solution as example, how do you extend Spring so that "who gets injected", "which bean is used to inject which component" kind of logic can all be centrally configured within Spring without explicit or implicit bidirectional coupling between config file and pojo?

    I know you can avoid the bean name and annotation if the property name and the bean name follow some predefined pattern, but that's just an implicit coupling.

    Traditionally, spring config files depend on pojo, but pojo doesn't depend back in any way. It's sad to see that elegance going away.
    I think you're missing the point on this, here and on the other thread where we discussed it.

    The coupling is one way only: the configuration information is resolved from the newly instantiated object awaiting injection. The information consists of bean definition or autowiring strategy. There is an interface responsible for this: BeanWiringInfoResolver. The default strategy looks for a bean definition with the same name as the class: ClassNameBeanWiringInfoResolver. But other strategies can be used. There is no dependence in the POJO on the Spring infrastructure, unless you choose to use the Configurable annotation, which is purely optional. Note that any other annotation--such as a JPA entity annotation--could also be used.

    The most important coupling is really the pointcut, which is completely external from the code affected by the injection. And AspectJ provides a very rich means of expressing this.

    Rgds
    Rod
  236. Spring 2.0 anemic domain model solution[ Go to top ]

    Spring's popularity owes much to the fact that it is very easy to extend compared to most frameworks.


    My comment--that Spring was easy to extent--was not subjective. I cited some of the many frameworks that extend Spring in a wide variety of ways. It's not just my opinion.

    I'm not sure if the reason why "most frameworks" are not as popular is because they are not as easy to extend.
    I've looked at Pico, nothing seems to prevent it from supporting the same level of extensibility as Spring. Though I'm not familiar with Hivemind, I kinda tend to believe that it is also easy to extend.

    This is just regarding the DI framework. I do think that Spring is successful in the area of aop, declarative transaction, and most importantly, a practical integration of many useful toolkits. People like to shop in Walmart rather than 10 different local stores.
    There is an interface responsible for this: BeanWiringInfoResolver. The default strategy looks for a bean definition with the same name as the class: ClassNameBeanWiringInfoResolver. But other strategies can be used.
    I was not quite clear about what you meant by the resolver interface. But I think now I understand it better. Thanks.

    This resolver interface is pretty much a mapper between pojo properties and appcontext beans.

    And I do think this is a good abstraction compared to the original example presented in Adrian's blog.

    The question now becomes: is this resolver configurable through spring? It's fine if the resolver simply implement some global mapping strategy like "byname", "byfqn" or "bytype", but when finer granularity is needed, it's a pain to have to hard-code the bean names in the resolver code (or, use @springConfigured).


    Finally, about _aware_, isn't it true that the dependency injection aspect has to implement ApplicationContextAware? That makes the aspect code unusable outside of spring. doesn't smell good to me.


    Ben.
  237. Spring 2.0 anemic domain model solution[ Go to top ]

    People like to shop in Walmart rather than 10 different local stores.
    Actually, they like malls because the stores are in one place. People go to Walmart because they're cheap or poor.

    Spring is more like a Boutique mall.
  238. Spring 2.0 anemic domain model solution[ Go to top ]

    People like to shop in Walmart rather than 10 different local stores.
    Actually, they like malls because the stores are in one place. People go to Walmart because they're cheap or poor. Spring is more like a Boutique mall.

    Indeed. He used Walmart because it was a cheapshot. The JBoss REALLY need to keep their people from posting.
  239. Spring 2.0 anemic domain model solution[ Go to top ]

    Have you ever saw a framework popular for technical reasons ?
  240. Have you ever saw a framework popular for technical reasons ?

    Yep. Spring. That fact everyone doesn't agree with those reasons is irrelevent. In this post, we've seen four camps:

    1) Bob Lee and Ben Yu who don't like it primarily, IMO, because they are working on competing products that are less successful.

    2) The "me-toos" that chime in because it is fashionable to bash the winner.

    3) The guys that don't like XML.

    4) Others, like yourself, no offense, who basically admit that they don't understand the value.

    Note that nones of those guys have actually USED Spring.
    Now, put that against, people who have used it, have derived value from it, have explained such value, and have actually garned success, in part, because of Spring, which camp would you plant yourself into?

    I'm going with the tool that has proven itself.
  241. Spring 2.0 anemic domain model solution[ Go to top ]

    Ben
    And I do think this is a good abstraction compared to the original example presented in Adrian's blog.
    I think some of the confusion stems from the fact that that blog was quite a long time ago, and the Spring 2.0 implementation has always been different (and better). The implementation is the only thing that has mattered, since December.
    The question now becomes: is this resolver configurable through spring?
    Yes, naturally.
    Finally, about _aware_, isn't it true that the dependency injection aspect has to implement ApplicationContextAware? That makes the aspect code unusable outside of spring. doesn't smell good to me.
    Yes, the aspect needs to get hold of the Spring container (actually through BeanFactoryAware). Its purpose in life is to dependency inject objects using Spring. It also depends on Spring's autowire semantics, so attempting to decouple it doesn't make sense IMO.

    No user will modify the aspect code (as opposed to optionally sub-aspecting to define pointcuts), so why is this a problem? Frankly, I think you're splitting hairs. Moreover, there is so little code in the aspect itself that any attempt to make an abstraction over the IoC container and autowire semantics would bloat it significantly.

    In any case (if I'm also allowed to split hairs), the aspect is not unusable outside Spring. BeanFactory is a very simple, well-documented interface. It does not pull in loads of Spring code. You could implement a facade BeanFactory over another IoC container APIs and use the same aspect. Which would probably make more sense than introducing a new abstraction, with effective duplication.

    Rgds
    Rod
  242. Spring 2.0 anemic domain model solution[ Go to top ]

    Yes, naturally.
    Can you post a link to a sample? What I'd like to see is the familiar spring configuration scheme, not a different set of configuration scheme introduced by whatever the resolver class. (through a map?)

    And, again, (not sure if you also consider this splitting hairs), does it work with inheritance? can I configure injection for Fruit, which natually works for Apple and Orange?

    About the aspect, yes, if it is just a matter of 5 lines of code, being able to reuse it outside of container isn't of much value. I was thinking there's a substantial amount of code involved.

    By the way, "sub-aspecting" a spring-proprietary aspect is a problem if we consider a "not-everyting-is-spring" world.

    I won't comment much on "a well documented interface is usable outside Spring". As a matter of fact, I do see acegi and spring mvc using lots of such "well documented" proprietary interfaces. Honestly I was not able to figure out an economic way to use them outside of spring.

    My problems with Sring so far:
    1. the SpringAware interfaces encourage code that's strongly coupled with the infrastructure.
    2. no private bean support. no namespace support.
    3. awkward syntax. (this is gonna change in spring 2, I suppose?)

    Ben.
  243. Spring ain't modular.[ Go to top ]

    But such marker interfaces make Spring very hard to be embedded.
    Ie, POJO is lost. Aspects blow containers away.
  244. Bob Lee: I Don't Get Spring[ Go to top ]

    Spring has a lot of advantages.

    1. IOC

    2. Templates for Hiberate etc which simply working with Hibernate

    3. Declarative Transaction Management which saves you from writing code related to transaction management and also avoid mistakes.

    People who could not explain the advantages of Spring may be did not use the features or understand the actual benefits spring is providing.

    But for simpler apps Spring may be unnecessary.
  245. Bob Lee Who????[ Go to top ]

    I bet this guy lee just got his Java Cert.

    I've been developing with spring for about 2 years now and its been great..instead of complaingin maybe he should start his own project and give some solutions...
  246. Life is not white & black[ Go to top ]

    Life is not 0 or 1...
    rather fractal, fuzzy, evolutionary (... see Darwin, Stephen Jay Gould http://home.planet.nl/~gkorthof/korthof63.htm),
    funky (... Talent makes capital dance http://www.funkybusiness.com/funky/).

    Bob, Rob are talented people.

    Spring is in evolution.

    "All evolution is due to the accumulation of small genetic changes, guided by natural selection [agency and efficacy], and evolution above the species level is nothing but an extrapolation [scope] and magnification of the events that take place within populations and species".
  247. Bob Lee: I Don't Get Spring[ Go to top ]

    I was assigned to a project a while back that used Spring. My only regret is that I didn't rip it out when I had the chance.  Why on earth would I want the overhead and head ache of those XML files when I know how to do it directly.  Create a DAO out of pure J2EE and use something like eclipse wizzards  to create new itmes ( Servlets, beans etc.. ) if you need help properly foming the skeletons. From what I can tell it's only use is resume building and book selling. Oh and trying to debug the stuff is a nightmare. Oh and I really don't get the "It doens't effect your code thing" I just tried to modify my web.xml file to add a utility servlet I wrote for another project.. I acutally had to ask somone else to "plug" my code so it would work.  I like to think I'm the tech's tech. I live for new technology but this is the 1st item that I've actually banned from my department.