Developing J2EE applications without Spring? Why?

Home

News: Developing J2EE applications without Spring? Why?

  1. Ugo Cei brought up a Matt Raible blog from The Spring Experience, pointing out that the upcoming Spring 2.0 release shouldn't break anything of any note. Spring 2.0 should be a drop-in replacement for Spring 1.x, and led Ugo to make a worthwhile statement: "I seriously wonder why anyone would want to develop anything substantial in Java nowadays without using Spring."

    What do you think of this statement? Would you consider Spring to be the beginning of correct implementation for your J2EE applications? With Spring being supported by BEA as well as Interface21, has Spring become a standard toolkit for J2EE developers? If not, should it be? Should it somehow be integrated further into Java, Enterprise Edition (perhaps 6.0?)

    Threaded Messages (175)

  2. I would only consider not using it for (very)small apps. For the bigger and more complex applications its almost a requirement.
  3. I do not think I need the reason not to use some stuff, it must be a reason to use. It is very silly to use this stuff for no reason, is not it ?
  4. I do not think I need the reason not to use some stuff, it must be a reason to use. It is very silly to use this stuff for no reason, is not it ?

    Juozas,

    Spring is not magic, but it does collect together a number of approaches to developing in Java that have been found over time to work well. As such, it is as much a collection of best practices as it is a framework.

    To me, it's no different than choosing between rolling your own O/R approach or using Hibernate or KODO .. anyone who is rolling their own today has to be nutz!

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  5. I see nothing wrong in Spring and I do not have any resons not to use it and if you will tell me a good reason to use it then probably I will use it too. Probably this hype on TSS is a good reason to use it, if it helps to sell application.
    BTW who pays for this kind of articles on TSS ?
  6. To me, it's no different than choosing between rolling your own O/R approach or using Hibernate or KODO .. anyone who is rolling their own today has to be nutz!

    Well, I guess I'm nutz. We built our own O/R framework. We've also built our own JDBC wrapper. All our frameworks are integrated and implement exactly the features we need and no others.
  7. Rod makes a compelling argument that there is no good reason to write your own persistence framework. Assuming your framework is a feature complete as Hibernate, JDO or even Spring's JDBC wrapper, which is hard to imagine, there is zero chance of finding new people who know how to use it. Also, any experience with it will be wasted when you move on to other companies.
  8. Well, I guess I'm nutz. We built our own O/R framework. We've also built our own JDBC wrapper. All our frameworks are integrated and implement exactly the features we need and no others.

    That approach works for companies with a large enough staff and enough attention to detail and good developer retention and a great environment of "knowledge sharing". I hope your company has all those things, since (IIRC) you also wrote your own app server. ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  9. Well, I guess I'm nutz. We built our own O/R framework. We've also built our own JDBC wrapper. All our frameworks are integrated and implement exactly the features we need and no others.
    That approach works for companies with a large enough staff and enough attention to detail and good developer retention and a great environment of "knowledge sharing". I hope your company has all those things, since (IIRC) you also wrote your own app server. ;-)Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java
    Do you think it is a good idea to use this heavy weight stuff for trivil thing like wrapper to convert SQLException to RuntimeException ? I agree, NIH is not a good way, but this stuff is too trivial, it must be better just to fork it, remove useless stuff and maintain it at home if you realy need it.
  10. That approach works for companies with a large enough staff and enough attention to detail and good developer retention and a great environment of "knowledge sharing". I hope your company has all those things, since (IIRC) you also wrote your own app server. ;-)
    True ;)
  11. To me, it's no different than choosing between rolling your own O/R approach or using Hibernate or KODO .. anyone who is rolling their own today has to be nutz!

    Unless of course you have a datamodel left over from the late nineties. They only thought about SQL and storage; they didn't care about "objects" that needed to read the data.

    I got tired of write Hibernate XML files to describe all the minute details. It was easier to write JDBC with some simple wrappers.
  12. Home grown persistence vs OR[ Go to top ]

    [To me, it's no different than choosing between rolling your own O/R approach or using Hibernate or KODO .. anyone who is rolling their own today has to be nutz]

    The persistence tier (atleast for most CRUD operations) is quite trivial to implement with either O/R mapping tools or a simple DAO-JDBC based approach.

    The persistence tier can be completely code-generated and that makes is irrelevent the choice of whether OR Tools are used or not. There is a place for commercial OR tools (depending on the extra value they add) and there is a place for home-grown(based on existing code-generation practices).

    No magic bullet for everything.
  13. Doesn't that depend on requirements?[ Go to top ]

    [To me, it's no different than choosing between rolling your own O/R approach or using Hibernate or KODO .. anyone who is rolling their own today has to be nutz]

    The persistence tier (atleast for most CRUD operations) is quite trivial to implement with either O/R mapping tools or a simple DAO-JDBC based approach. The persistence tier can be completely code-generated and that makes is irrelevent the choice of whether OR Tools are used or not. There is a place for commercial OR tools (depending on the extra value they add) and there is a place for home-grown(based on existing code-generation practices). No magic bullet for everything.

    I don't agree that CRUD operations is simple. It all depends on the scope and features one includes in the CRUD. Say you have a complex object model. Does the CRUD handle things like uni-directional and bi-directional relationships? Are developers responsible to keeping track of which objects need to be deleted to insure data integrity.

    For example, say I have a model that has Customer, Account, Address, Phone and Email objects. What happens when I define the relationship between Account and Address as one-to-one and bi-directional? If I try to delete the address without deleting the Account, will the CRUD layer handle that? What happens if I change the model to one-to-many unidirectional?

    There's all sorts of CRUD, but calling it CRUD is overly general. I think it's more accurate to call it object persistent layer. A simple persistent layer that doesn't handle relationships isn't really going to make life any easier for developers. It's just different. On the otherhand, if the persistent layer understands the model and is able to make sure delete/updates conform to the model, then it can save development time.

    my 2 cents worth of gibberish.

    peter
  14. CRUD/Code Generation[ Go to top ]

    [I don't agree that CRUD operations is simple. It all depends on the scope and features one includes in the CRUD. Say you have a complex object model. Does the CRUD handle things like uni-directional and bi-directional relationships? Are developers responsible to keeping track of which objects need to be deleted to insure data integrity.]

    My arguments for a home-grown approach was based on the following being available:

    An object model that is decorated/annotated so that the code generation tools can generate all classes that conform to say..the DAO pattern.

    From the model, one could generate Spring/Hibernate code, DAO code or any O/R type code.

    80% of CRUD operations fall into patterns that can be completely code-generated.
  15. CRUD/Code Generation[ Go to top ]

    [I don't agree that CRUD operations is simple. It all depends on the scope and features one includes in the CRUD. Say you have a complex object model. Does the CRUD handle things like uni-directional and bi-directional relationships? Are developers responsible to keeping track of which objects need to be deleted to insure data integrity.]My arguments for a home-grown approach was based on the following being available:An object model that is decorated/annotated so that the code generation tools can generate all classes that conform to say..the DAO pattern. From the model, one could generate Spring/Hibernate code, DAO code or any O/R type code. 80% of CRUD operations fall into patterns that can be completely code-generated.

    I don't know that it's 80%, but I agree there's plenty of cases where code generation is appropriate. In those cases though, I question the value of using Spring. I'd just use Tomcat and a simple data access layer to provide a clean separation.

    peter
  16. CRUD/Code Generation[ Go to top ]

    [I don't agree that CRUD operations is simple. It all depends on the scope and features one includes in the CRUD. Say you have a complex object model. Does the CRUD handle things like uni-directional and bi-directional relationships? Are developers responsible to keeping track of which objects need to be deleted to insure data integrity.]

    My arguments for a home-grown approach was based on the following being available:

    An object model that is decorated/annotated so that the code generation tools can generate all classes that conform to say..the DAO pattern.

    From the model, one could generate Spring/Hibernate code, DAO code or any O/R type code.

    80% of most CRUD operations(the 80% is just a guideline..it could be different..but the idea is to automate the easy stuff) fall into patterns that can be completely code-generated.
  17. I think majority of people don't use Spring.

    "Just" a few use Struts w/o IoC or Spring, we use CoR :-)
    and there is 1 or 2 other frameworks out there.

    Majority of times you don't need transactions, only minority of times do you connect to 2 dbs. Sometimes no need for AOP.
    Spring's big sale is that it would isolate EJB so one could implement something else.

    Has Spring caught up to Struts % of market share even?

    Spring seems heavier than Struts, and ... I think one of the reasons for Ruby defections. (vs Struts or Shale, that are much ligher and can get our of your way).

    I used to think complex = sophisticated for the 1st 7 years of developing, now I reject that bigger applications need more complex framework, I now think the oposite, the bigger the app is the more leads need to concetrate to simplify.

    KISS.

    .V
  18. Spring is simple[ Go to top ]

    Spring is simple.

    I think we will see more and more projects where spring will play an important part of a less complex more elegant solution.

    It has certainly cut down my code base and made the software I create more flexible to meet the needs of new requirements as they roled in.
  19. comparing srping to struts is plain silly. There may be some point in comparing spring-mvc to struts but spring in general provides way more stuff.
    I can not think of any app, big or small, without spring. Spring is not just a framework, it is also a way of developing java software in a decoupled and clean way.
  20. ... spring in general provides way more stuff.

    Yes!!

    It even has a way to go from OR to SQL based DAO. Do I need that?
    Like training wheels, that you can kick of, once you can make a choices... to use collections instead of beans, to use scripting lang such as groovy (Struts has scripting support for Groovy!)
    All I said is that it does not most in market share, as per Dice.

    It's got good things, like remoting and a C# version. I will review the version 2 once it's out to see if it's simpler than alternatives.

    .V
  21. Yes!!It even has a way to go from OR to SQL based DAO.

    I don't understand what you meant? What spring provides is a clean way to switch implementations of beans without changing a single line of code, whether they are daos or not.
    The beauty of spring is not just what it provides, is also the way it provides it. it does it in an elegant, simple, flexible, non-intrusive way.
    Spring is not a technology you have to adjust to in order to use it, it is a framework to make java code cleaner, more testable and simpler. If you think of spring for what it provides in terms of technology integration, you will be missing the whole point of it.
    Again, I can't think of a reason not to use it.
  22. Again, I can't think of a reason not to use it.
    I have no reasons not to use COBOL to develop large and small applications. Is it a good reason to use it too ?
  23. I have no reasons not to use COBOL to develop large and small applications. Is it a good reason to use it too ?

    Neither do I since I don't know COBOL. And I think this might just be the case with you and spring. But you know what, you may be right, using spring for every single application might be overkill. However, not using dependency injection, whether it is using spring, picocontainer, plexus or any other dependency injection container is absolutly out of my way of thinking, if my app is not constrained in a way that won't allow for the introduction of these containers (there goes a reason not to use it).
  24. If not knowing a language was a justifiable reason NOT to use it, how did you start learning Spring ?

    I know both COBOL and Spring and I can honestly say there is are use cases for using both/either of them.
  25. If not knowing a language was a justifiable reason NOT to use it, how did you start learning Spring ?I know both COBOL and Spring and I can honestly say there is are use cases for using both/either of them.

    Spring is not a programming language either..
  26. Spring is good stuff[ Go to top ]

    Spring is good stuff.
  27. Disclaimer: I like IoC/Dependency Injection and use it with my applications, most often in the form of Spring. This post is about this topic, not other things Spring provide (I know there's more to it).

    But then, I don't see why people get THAT exited about Dependency Injection, sure its nice, but the lookup pattern serves the same use case and not with that much difference (don't confuse this with JNDI, looking up something there is quite (too) complex... there are other lookup mechanisms) and has been used for ages, DI doesn't improve on the core of the problem, it rather provides a (little) advantage in how the pattern is implemented.

    Opinions?

    kind regards,

    Messi
  28. Personally I hate wiring up my Service-DAO layer via Spring xml-config. I do it because that way I may use HibernateDaoSupport which makes things easier in DAO. Templates are the best part of Spring for me.

    But I certainly don't like using abstract factory pattern and IOC xml-wiring all the time to instantiate DAOs (I know that my application database won't ever change). Yep, it's not hard but I still think it takes too much time (writing the xml, catching all the runtime errors because of small typos etc.)

    I may be alone with my statement, but I think using dependency injection is not the fastest nor easiest way to code the application.

    Tomi
  29. All of this talk about Spring being unobtrusive and invisible is just plain wrong. That might be true fo the IoC component of Spring but for everything else like wrapping data access logic in Spring specific Templates (e.g. HibernateTemplate) only further clutters things IMO. Do a search on the Hibernate forum nad you'll fund over 1000 questions dealing with Spring integration.

    Just like everything else in the development world. There is no 1 correct way for anything let alone everything.
  30. All of this talk about Spring being unobtrusive and invisible is just plain wrong. That might be true fo the IoC component of Spring but for everything else like wrapping data access logic in Spring specific Templates (e.g. HibernateTemplate) only further clutters things IMO. Do a search on the Hibernate forum nad you'll fund over 1000 questions dealing with Spring integration. Just like everything else in the development world. There is no 1 correct way for anything let alone everything.

    Well, that is a choice. You don't have to use Spring's integration with Hibernate. Regardless, we do use it and it still doesn't clutter anything. In fact, Hibernate is much easier. We have two apps that use Hibernate w/o Spring and 6 that use Hibernate w/ Spring. The 6 are simpler. In fact, one of our guys has worked on both and he'd never use Spring or Hibernate before and he believes that the Spring/Hibernate combo is better.

    If you do it the right way, you'll barely see Spring in the data access code.
  31. Majority of times you don't need transactions, only minority of times do you connect to 2 dbs

    Huhh? What is the link between whether or not to need transactions, and the number of databases? Whether, or not, you need transactions, is clearly a requirement of a system or business operation (or whatever granularity you consider). It ain't got nothing to do with the # of DBs (# > 0). I would agree, that when you got 0 DBs, you don't need transactions :-)

    Regards,
        Dirk
  32. I think majority of people don't use Spring."Just" a few use Struts w/o IoC or Spring, we use CoR :-)and there is 1 or 2 other frameworks out there.Majority of times you don't need transactions, only minority of times do you connect to 2 dbs. Sometimes no need for AOP. Spring's big sale is that it would isolate EJB so one could implement something else. Has Spring caught up to Struts % of market share even?Spring seems heavier than Struts, and ... I think one of the reasons for Ruby defections. (vs Struts or Shale, that are much ligher and can get our of your way).I used to think complex = sophisticated for the 1st 7 years of developing, now I reject that bigger applications need more complex framework, I now think the oposite, the bigger the app is the more leads need to concetrate to simplify. KISS..V

    Simplicity is what Spring brings to the table. My apps are, without a doubt, simpler and easier to understand. Why? Because with Spring, my business logic contains just that. Caching, Transactions, which every app needs, Security, and now profiling is handled in AOP Interceptors. My architecture is just a set of java beans. In fact, a third person recently wrote a utility that was able to use our business interfaces for this project and by using Spring to create the objects in question, his standalone app(ours is a web app) was able to work with minimal effort on his part. In fact, with NO effort on his part, he got transactions, caching, and profiling(didn't need security, so we removed this from the xml file), the same items that the web app received.

    Spring clearly makes sense.
  33. Comparing Struts With Spring?[ Go to top ]

    <quote victor c>
     Has Spring caught up to Struts % of market share even?
    </quote victor c>

    So obvious that you have a very shollow understanding of what Spring is. Why do so many ppl like to comment something that they do not really even know? Kick this habit for peter's sake.
  34. fantastic...[ Go to top ]

    I'll guess i'll stop using transactions for that app that updates two seperate tables in one update....
  35. Well, I dont't think it's smart to compare spring with struts, those are differ. its better to compare struts to spring-mvc.
    However, spring provider more stuff, such as AOP, Tranaction, and other helpfull tools to make our work simply, so that we can focus on the more important things: domain special.
  36. Spring's big sale is that it would isolate EJB so one could implement something else.

    This is often said, but I don't think it is the case. My view is that dependency injection (DI)is still very much misunderstood in the same way as, for example, object orientation was a couple of decades ago. It used to be that OOP was considered a great way to handle things like GUI entities. It took some time before it was generally realised that OOP was a far more general technique and could model things like processes as well.

    In the same way, I think DI is a powerful and very general way of decoupling objects, and is just as important in J2SE and even J2ME as in server side Java. It is not just a way of assisting with J2EE development.
  37. My view is that dependency injection (DI)is still very much misunderstood in the same way as, for example, object orientation was a couple of decades ago. It used to be that OOP was considered a great way to handle things like GUI entities. It took some time before it was generally realised that OOP was a far more general technique and could model things like processes as well.
    Yes OOP was a good thing before it was misused for stuff like modeling and databases, dependency injection and IoC stuff was not so bad too (Apache Avalon) before it was misused for contract in XML.
  38. Security[ Go to top ]

    Yes I'm new. I might be wrong etc, but:

    Spring is normally used on a client directly coupled to the database, right? (yes, it could be used above some remoted func like ejb but that's kinda abnormal usage it seams). Now, does not having the client (webserver being a common one) directly connected to a database present a big security problem?

    Kind regards and in appreciation of any thoughts on this
    /Johan Rylander
  39. Security[ Go to top ]

    I think you didn't get the point of Spring.

    Spring allows you to write any components using POJO. The principle behind this is : "OO design is more important than any implementation technology, such as J2EE". You don't have to structure your code based on deployement, components requirements (EJB interfaces...).

    Anyway, about security, I don't see any problems about a client connecting straight to a database. Server-client applications were there a long time before JEE was even borned.
  40. Good but not standard[ Go to top ]

    Java has std framework for building page flows -> JSF. However AJAXed sites are following Swing like approach for web. It's very nice to develop one GUI and then just DEPLOY it as:
    - Swing app
    - Web app (without JavaScript)
    - AJAXed web app
  41. Why not? Spring gives me nothing I need. The difficulty of J2EE is greatly overstated. I can understand why people new to J2EE and similar might want to use Spring.
  42. Why not? Spring gives me nothing I need. The difficulty of J2EE is greatly overstated. I can understand why people new to J2EE and similar might want to use Spring.

    William,

    I'd suggest you need to give Spring a closer look, because it does help in many ways, but one in particular is in testing. It is too easy for JEE application components to end up as untestable without the presence of a container.

    Spring also makes application development easier as well as faster, but I'll stop here -- your suggestion that "people new to J2EE and similar might want to use Spring" is as ridiculous as "difficulty of J2EE is greatly overstated".

    JEE application is very difficult, and if you feel this way, you're either a genius or you don't know what you're talking about.

    Thomas
  43. I think Spring has a branding problem. Some of the posts on this thread are evidence of that... many people don't really understand what Spring is.

    I think that Spring should be two separate things. The first is an IoC container, which (as James Strachan pointed out) you can use without a single dependency on Spring in your code. It's invisible to your code, and it helps you to follow good programming practises such as coding to interfaces, designing for testability, and so on. Note that the IoC container is nothing to do with J2EE, although you can use it within a J2EE application.

    The second part of Spring is a library (or collection of libraries) that is useful in certain situations. You can pick and choose what you want to use from this library, depending on what you're doing. For example, if you're accessing a database with pure JDBC code, you can use Spring's JDBC library as a higher-level abstraction. In fact you *should* use it because it's almost certainly far more robust than the JDBC code you write in-house.

    Because of Spring's branding problem, people get a lot of different messages about what Spring really is, which is the reason for a lot of these ignorant posts. Too many people seem to be getting the message that "Spring is for stupid people who can't do J2EE" or "Spring is AOP" or "Spring is Hibernate".

    Now, am I using it? Yes, I'm using parts of it. It's such a high quality library of code that the decision to use it is almost a no-brainer. Am I using all of it? Of course not, and I don't think anybody is.
  44. I think that Spring should be two separate things. The first is an IoC container, which (as James Strachan pointed out) you can use without a single dependency on Spring in your code. It's invisible to your code, ...

    Unless, of course, you consider configuration files to be part of your code. I think, if we fail to consider system complexity as a whole and over the entire life cycle, we will always just be shifting complexity around. A framework should be judged by what it means for all the processes comprising system development, maintainance and operation. Clearly, externalizing some indispensible parts of the system into XML files, doesn't fundamentally change the dependency picture. It just changes the dependency graph for some components and processes in the system, which may be a good thing.

    This isn't an argument against Spring. In fact I'm looking at Spring much more favorably than I used to. IoC does actually reduce some complexity by inferring the correct sequence of object instantiations. This is not just shifting complexity around. This is complexity reduction. AOP (another feature of Spring's object instantiation facility) also reduces the complexity of some tasks (although the IMO the jury's still out on the complexity of maintaining AOP based systems).

    But all of this doesn't mean that there are no dependencies on Spring for IoC. Of course there are, if code is defined as everything developers have to write to make the system work.
  45. I recently started on an existing project of around 2 years old. It was developed by students and kicked off by Alev. I had no spring experience and no one to get me started because everybody left the company. I therefore consider myself the perfect testcase for the maintainability of a system developed in spring. My opinion.

    - AOP is evil. I hate it. Debugging is nightmarish. Guys stop it!
    - Configuring in XML is a pain. No reference search anymore, no easy navigation with help of eclipse, back to ctrl-f all day. Java based DI is coming up though, that would improve a lot in this area.
    - Spring MVC is a lot like struts, painfull drop it in favour of a component model.
    - Spring forum is very helpfull, couldn't live without it.

    I also guide some people that have no web experience at all. They are good programmers though. Spring == J2EE made easy but Spring != easy. It is funny to see them wonder about how many things they have to do to before something works. Spring does NOT make web development easy, it makes j2ee in some parts easier but not development outside the j2ee context. Anybody that does not agree with this is brainwashed by years of very complex j2ee.
  46. I think Spring has a branding problem. Some of the posts on this thread are evidence of that... many people don't really understand what Spring is.I think that Spring should be two separate things. The first is an IoC container, which (as James Strachan pointed out) you can use without a single dependency on Spring in your code. It's invisible to your code, and it helps you to follow good programming practises such as coding to interfaces, designing for testability, and so on. Note that the IoC container is nothing to do with J2EE, although you can use it within a J2EE application.The second part of Spring is a library (or collection of libraries) that is useful in certain situations. You can pick and choose what you want to use from this library, depending on what you're doing. For example, if you're accessing a database with pure JDBC code, you can use Spring's JDBC library as a higher-level abstraction. In fact you *should* use it because it's almost certainly far more robust than the JDBC code you write in-house.Because of Spring's branding problem, people get a lot of different messages about what Spring really is, which is the reason for a lot of these ignorant posts. Too many people seem to be getting the message that "Spring is for stupid people who can't do J2EE" or "Spring is AOP" or "Spring is Hibernate".Now, am I using it? Yes, I'm using parts of it. It's such a high quality library of code that the decision to use it is almost a no-brainer. Am I using all of it? Of course not, and I don't think anybody is.

    Mr. Bartlett, very well said. +1
  47. JEE application is very difficult, and if you feel this way, you're either a genius or you don't know what you're talking about.Thomas

    Well maybe I'm a genius or maybe I've just been building these sorts apps (distributed OLTP, SOA, etc.) for a long long time. JEE has a steep learning curve if you never broke the code with CORBA or Tuxedo. Its less steep, but not trivial if you have. However, most of the problems only have to be solved once if you approach them correctly.

    If you keep your business logic out of the EJBs and let the container manage your transactions and avoid Entity Beans altogether you can keep things reasonably simple. If all your EJBs do is delegate to POJO business objects then how many different ways do you need write an EJB? They are merely facilities for communications, management, and thread management. You can write a generator for them for heaven's sake. Unless you change application servers every day, the results become predictable. If your EJB has just one method that receives a message object then you have even less work to do.

    MDB's are even easier. You can write one or two and then extend them(to get the unique class name) to handle almost all your requirements. Just pass the message on to your service proxy POJO. Serlvets, the same.

    It seems to me that people think JEE is hard (and remains so) because they try to make its containers and classes (EJBs, Servlets, etc.) do too much. Let them provide the services while you do your work in POJOs.
  48. If you keep your business logic out of the EJBs and let the container manage your transactions and avoid Entity Beans altogether you can keep things reasonably simple. If all your EJBs do is delegate to POJO business objects then how many different ways do you need write an EJB? They are merely facilities for communications, management, and thread management. You can write a generator for them for heaven's sake. Unless you change application servers every day, the results become predictable. If your EJB has just one method that receives a message object then you have even less work to do.MDB's are even easier. You can write one or two and then extend them(to get the unique class name) to handle almost all your requirements. Just pass the message on to your service proxy POJO. Serlvets, the same.

    Yeah and then you end up with like what 100 factories or singleton. That's exactly one of the purpose of Spring. It helps you respect those best practices (keeping logic out of JEE components and put it in POJO) and you end up not having to code all of those factories (or other creational patterns), wich are in my opinion plumbing code where I don't want to waste my time. In no time, I can switch some beans to use a remote EJB instead or a Mock test object without having a single factory method to write. In my case, I have saved lot of time using it. Plus, the pooling and caching of objets are already provided. I view the IoC container of Spring as being a *factory framework*.
  49. If you keep your business logic out of the EJBs and let the container manage your transactions and avoid Entity Beans altogether you can keep things reasonably simple. If all your EJBs do is delegate to POJO business objects then how many different ways do you need write an EJB? They are merely facilities for communications, management, and thread management.

    But I think this is exactly the reason why people use Spring. Spring is the container, which is why Spring is always compared with J2EE. Write the business logic in POJOs, then wrap the other services around them declaratively.

    And the benefit of Spring is that it doesn't rely on a J2EE container, so it fits better with the requirements for smaller apps, eg. Tomcat.
  50. J2EE sometimes has unneeded difficulty, it's not as simple as it should be. Why make it more difficult than it needs to be?

    Some Examples:
    Using EJB's to create web apps that don't need distributed objects. You'll needlessly have to pick up some of the complexities, and non-OO hacks, needed for distributed objects.

    Spring's Templates can reduce the boilerplate code while simplifying persistence, messaging,...
  51. What will be interesting to see is how many Spring followers drift back toward the 'standard' J2EE stack once EJB 3.0 is production ready. I've yet to use it, but it sounds quite good.
    Mike
  52. What will be interesting to see is how many Spring followers drift back toward the 'standard' J2EE stack once EJB 3.0 is production ready. I've yet to use it, but it sounds quite good.Mike

    I don't think many because EJB3, from what I've seen, just isn't that compelling if you are already using Spring.
  53. I use Spring as a Dependency Injection container and to perform some AOP such as for declarative transactions or security interceptors etc.

    For me the big advantage of Spring is that for the most part its completely invisible to my application code since it just performs all the dependency injection using regular POJOs.

    Discussions such as but its not a standard are kinda meaningless when talking about dependency injection, since the whole point of dependency injection is that the framework is invisible to your application code. You only need to standardise visible APIs and annotations.

    James
    LogicBlaze
  54. Please clarify what you mean by substantial. Otherwise the statement is too open ended to serve as a basis for discussion. I would have preferred if the discussion was "What constitutes the threshold where using Spring really does simplify your web app?"

    I have tried to justify Spring for a few typical web applications, but honestly I couldn't justify it, because it did not make the application simpler. I wanted to use Spring, but the line count increased when I did, and when I got some code walk throughs from colleagues who were advocates, I saw little that would help my code. Well except for the way they wrap hibernate transactions... that was cool... but using Struts (or your own favorite mvc framework), with Hibernate is just not that hard, and if you apply a couple of patterns, it's even easier.

    I assume that for large scale enterprise apps Spring has good use, and can corral wild architectures, especially whan you have a ton of config files, and disparate developers, but for your typical web app which just updates/reads a database, and generates a web page... well there's very few problems to solve really, if you code half decent.
  55. Please clarify what you mean by substantial. Otherwise the statement is too open ended to serve as a basis for discussion. I would have preferred if the discussion was "What constitutes the threshold where using Spring really does simplify your web app?" I have tried to justify Spring for a few typical web applications, but honestly I couldn't justify it, because it did not make the application simpler. I wanted to use Spring, but the line count increased when I did, and when I got some code walk throughs from colleagues who were advocates, I saw little that would help my code. Well except for the way they wrap hibernate transactions... that was cool... but using Struts (or your own favorite mvc framework), with Hibernate is just not that hard, and if you apply a couple of patterns, it's even easier. I assume that for large scale enterprise apps Spring has good use, and can corral wild architectures, especially whan you have a ton of config files, and disparate developers, but for your typical web app which just updates/reads a database, and generates a web page... well there's very few problems to solve really, if you code half decent.


    I've used Spring for two apps that were 2 and 3 pages long. Why? Because with Spring(and Hibernate and Struts), I was able to use the same architecture as the large apps I've worked on. So when new people joined, I let them look at those smaller apps to understand the larger ones.

    I wouldn't hesitate to use Spring for even small apps.
  56. Ah but by that argument one could use EJB for small apps! I often write quick and dirty struts apps that might be simpler as a couple of jsps, and I don't attach much significance to that.

    So what I'm still looking for is that threshold (the "substantial") at which Spring really does make your app simpler to fulfill and maintain.
  57. Ah but by that argument one could use EJB for small apps! I often write quick and dirty struts apps that might be simpler as a couple of jsps, and I don't attach much significance to that. So what I'm still looking for is that threshold (the "substantial") at which Spring really does make your app simpler to fulfill and maintain.

    I hate it just as much as the next guy when people mention other products, but check out Seam
  58. Ah but by that argument one could use EJB for small apps! I often write quick and dirty struts apps that might be simpler as a couple of jsps, and I don't attach much significance to that. So what I'm still looking for is that threshold (the "substantial") at which Spring really does make your app simpler to fulfill and maintain.

    Not really because Spring scales down and EJBs don't. Ultimately, it comes down to this, if you read about Spring and don't believe it would be useful to you, it probably isn't.

    I read about the concepts that lead up to Spring in Rod Johnson's J2EE Design and Development and agreed. Spring is the natural conclusion of those concepts, hence, I use it. We've seen the benefits and have won work because of it.
  59. I have tried to justify Spring for a few typical web applications, but honestly I couldn't justify it, because it did not make the application simpler. I wanted to use Spring, but the line count increased when I did, and when I got some code walk throughs from colleagues who were advocates, I saw little that would help my code. Well except for the way they wrap hibernate transactions... that was cool... but using Struts (or your own favorite mvc framework), with Hibernate is just not that hard, and if you apply a couple of patterns, it's even easier. I assume that for large scale enterprise apps Spring has good use, and can corral wild architectures, especially whan you have a ton of config files, and disparate developers, but for your typical web app which just updates/reads a database, and generates a web page... well there's very few problems to solve really, if you code half decent.

    How Spring can benefit you depends entirely on what you consider to be a benefit to a project first of all. Secondly, I have a feeling lots of people in this discussion are mixing Spring in general, with Spring MVC, which is just the web framework piece of Spring. I've never used Spring MVC for anything whatsoever. But I almost swear by the general Spring framework.

    As for Spring having caused your line count to increase, I guess that would depend on how you were developing prior to using it. For example, prior to using spring, I tended to write fairly tightly-coupled code. As such, I seldom if ever defined interfaces for classes. So yes, prior to Spring, I probably created fewer class files and such. And, I seldom made use of factories or singletons (just occassionally but I wasn't very consistent). Now I would say in retrospect that since I wasn't using Spring, or something like it, I should have been making heavier use of Factories and maybe singletons (though I know now they too can be somewhat questionable) to help decouple my code. I now place higher value on writing decoupled code primarily because it makes my code easier to test. I now place higher value on being able to test my code too. I didn't place high value (because I didn't know much about theories behind the practices) on testability of my code and how to achieve that. If you don't place much value on that, and/or if what you think of as testable code, is significantly different from what people like Rod Johnson (co-creator of Spring - and many others) seem to think of as tesable code, then a huge benefit of the general Spring framework goes to waste. So to appreciate some of what I consider to be the base benefits of Spring, you must first agree with the notions from which Spring evolved. Those notions are basically that code should be loosely coupled and easily testable (and there's a certain way in which you should be testing too). If you already agree with those notions and strive to comply with them in your code now, and strive to test in the ways lots of smart envangelists generally say to, then without Spring, you'll likely be going through some hoops creating lots of factories, service locators, interfaces (no getting away from those even with Spring though), etc.

    Do you have to code using all those constructs mentioned above? No. Of course not. Lots of crappy software is written everyday without any of that stuff. And the sad thing is that lots of people don't even know their software is crappy, just because it HAPPENS to work - I was one of them. They don't know development could be easier and less guess-ridden.

    Also (sorry this is getting long), I don't generally use the Spring HibernateTemplate. You can use Spring to the max benefit without using the hibernate template and still benefit from spring's transactional support. I inject my DAOs with spring's hibernate session factory LocalSessionFactory (I think) and call sessionFactory.getCurrentSession on that guy and then I'm doing standard hibernate queries and such. AFAIK, the only diff is that if you're using Hibernate2 or earlier, you'll have to catch hibernates exceptions and decide what to do with them. If you're using Hibernate3, they've switched those to runtime exceptions, which is what spring's hibernate template does, so you don't necessarily have to catch them. Also, the hibernate template translates hibernate exceptions to standardized spring exceptions so that you can change from hibernate to another persistence strategy like jdo or jdbc or whatever without having to change code outside DAOs that's calling those DAOs have dealing with any exceptions thrown by them. If you're darn sure you'll always be using Hibernate or you don't care, you need not use hibernate template at all.

    OK, I'm done...
  60. ..."I seriously wonder why anyone would want to develop anything substantial in Java nowadays without using Spring."

    Because I'm a contrarian.
    ...has Spring become a standard toolkit for J2EE developers? If not, should it be? Should it somehow be integrated further into Java, Enterprise Edition (perhaps 6.0?)

    Yes, and while we're at it we'll rename Java "Spring". All developpers will think and act alike. Innovation, creativity and free-thought will be banned. It will be a manager's utopia. I'm thrilled with the possibilities!
  61. Yes, and while we're at it we'll rename Java "Spring". All developpers will think and act alike. Innovation, creativity and free-thought will be banned. It will be a manager's utopia. I'm thrilled with the possibilities!
    Based on this description, wouldn't ".NET" be a better name ?
  62. What was the question/comment?[ Go to top ]

    Is Spring a descendent of the Catholic, Protestant, Jewish, Islam, or some tribal religion?

    steve
  63. What was the question/comment?[ Go to top ]

    Is Spring a descendent of the Catholic, Protestant, Jewish, Islam, or some tribal religion?steve

    Do you mean a sect of one of those? As far as I know, no one is born a Catholic or Protestant. Well Jewish maybe, but I believe you mean the religion and not the race so one wouldn't be that either.
  64. contrarian?[ Go to top ]

    Why? 1) Spring gives you a 'leg up' - instead of the coding the mundane, Spring abstracts it from you so you can focus on domain specific code. Why build a framework from scratch when you can leverage a best of breed one? 2) Spring gives you consistency, ease of maintainability. Using Spring on your project [with many developers] allows a standard way of how to do things. If you were one of many authors writing one book [e.g. Wrox books], you would have (want) to follow some type of writing pattern, layout standard etc. Spring allows such standards when writing Java EE code. Configuration, JDBC access, Logging, and more can be handled and written in a uniform way. This should make maintenance easier. Innovation, creativity and free-thought should be limited! Those characteristics are left for the application architect.
  65. Spring has somewhat blossomed into it's own 'language'. While the features it provides are quite useful, I'm afraid some developers, when approached with a problem, may opt to solving it via AOP or Spring-specific functions when it could have been implemented right in Java.

    I agree with others that Spring doesn't need to be a 'standard', but when developers start writing their apps for Spring, it does raise some questions. Granted your code doesn't include anything Spring-specific, but your application logic may rely on Spring to setup/configure/decorate/intercept to even operate.

    -- Jacob
  66. Spring has somewhat blossomed into it's own 'language'. While the features it provides are quite useful, I'm afraid some developers, when approached with a problem, may opt to solving it via AOP or Spring-specific functions when it could have been implemented right in Java.I agree with others that Spring doesn't need to be a 'standard', but when developers start writing their apps for Spring, it does raise some questions. Granted your code doesn't include anything Spring-specific, but your application logic may rely on Spring to setup/configure/decorate/intercept to even operate.-- Jacob

    It is high time that few companies stop being arm chair thinkers and decide for rest of us on how to build apps. A standard becomes standard not just with blessings of committies formed by big corps, but when it is made to solve real problems which developers experience on a daily basis. Sun is never known to have written an enterprise class application - it is famous for H/W and OS. When they made J2EE (ably assisted by other warring competeitors) based on what they thought distributed applications should be done it resulted in a disaster called EJB. Spring on the other hand evolved from the pains of ordinary developers. It is bottoms up approach to solve daily problems. It is time people stop preaching - should not do this and that and let developers decide what is best for them. And what ever wins is the de facto standard. In the history of computing never has a thrusted standard won. It has always been that many technologies evolved and the most popular ones survived as standard or converted into a standard. Remember how many non TCP/IP based protocols existed in networking space and now we dont even hear about them. While I can understand JBOSS guys vested intrests in shouting at the top of their voice their new found liking for standards, I do not understand why people like Jacob and Steve keep continously supporting Sun. Let people decide what is useful not Sun, IBM, BEA.
  67. Well fact is[ Go to top ]

    That spring evolved partially from EJB, but cleaned up the patterns and gave a good implementation and now EJB3 clearly is derived from Spring, which is a good thing.
    You can see at least in the java standards space that the standard makers have started to look at other solutions and try to put them into a common clothing.
    EJB3 is a typical example JSF as well, JDBC was also one of those.

    EJB1 and 2 was not, the idea was derived from Webobjects but they did not think of the ease of use.
  68. Spring is more than one thing[ Go to top ]

    Spring IOC/DI is an invaluable addition to my repertoire. I will probably never write another Java app of any size that doesn't include spring.jar because of this. (Until the next big thing comes out! ;))

    Spring for testing (spring-mock.jar) is also absolutely invaluable, although obviously I can't say that 100% of my projects which use spring.jar will also include spring-mock.jar. Most will.

    Spring DAO / Transaction support seems quite useful, although I haven't had the chance to use them personally. We do use it in our work, and I believe they're proving their value. That's even while integrating with Hibernate; I think the profusion of Spring posts on Hibernate forums is more of a measure of success for Spring than failure. My team's most junior developer figured it out (from scratch) with no external support.

    ACEGI / Spring Security has been mostly unhelpful to us. I don't believe I'd use this on most projects, but it's a separate JAR/package so there's no need to include it.

    Spring MVC I invested a lot of time and energy into learning, and I've come to the conclusion that as a framework it's still too immature to be a default inclusion in my toolkit. I'm currently evaluating WebWork as a replacement. Spring MVC has a lot of promise, but today it's still guilty of making easy things complicated.

    Spring AOP is one of the last big pieces of Spring that I've had no cause to use yet, so I have no opinion about it yet. It seems potentially quite useful, if less full-featured than AspectJ.

    --James
  69. Spring is more than one thing[ Go to top ]

    Spring AOP is one of the last big pieces of Spring that I've had no cause to use yet, so I have no opinion about it yet. It seems potentially quite useful, if less full-featured than AspectJ.--James

    My understanding is that they *choose* to make Spring AOP less than full featured. To focus only the items they judged most used by developers. I think that this was a good call.

    I was working on my on dynamic proxy interface layer that I had in place, but about a year ago, threw it out because Spring's was just more advanced. It took me one day to do that conversion and I've never looked back. We now have transactions(Spring provided), security, caching, and profiling all handled by Spring AOP and the business logic is much cleaner for it. Next step with be using the Exception advice to consolidate exception handling and then introduction messaging into our framework.

    Spring's approach made AOP easy, approachable, and immediately useful.
  70. Spring is more than one thing[ Go to top ]

    My understanding is that they *choose* to make Spring AOP less than full featured.

    Now you're just being silly. Spring clearly implemented the low-hanging proxy fruit in their initial AOP implementation.

    They have hired Adrian Coyler into a prominent position specifically because they want a full featured implementation of Spring AOP ready for release 2.0.
  71. Spring is more than one thing[ Go to top ]

    My understanding is that they *choose* to make Spring AOP less than full featured.
    Now you're just being silly. Spring clearly implemented the low-hanging proxy fruit in their initial AOP implementation.They have hired Adrian Coyler into a prominent position specifically because they want a full featured implementation of Spring AOP ready for release 2.0.

    No, I'm not being silly. If you read the J2EE without EJB book by Rod Johnson, I believe you'll find the origin of my statement.
  72. Spring is more than one thing[ Go to top ]

    I read the book, and have recommended it to friends. And, no offense, but it's not the Bible, just because he says their reason for something was one thing doesn't mean that's _actually_ the reason, or the only reason. It sounds like you're in some sort of consulting business, so I'm sure you've had the experience of justifying a solution to a customer using a rationale that wasn't the entire story, or probably even your original motivation. Serendipity is nice that way.

    I am perfectly willing to believe that Rod Johnson et al have made a virtue of their 'lightweight' AOP solution, but that doesn't mean they won't add more features to it over time.
  73. Spring is more than one thing[ Go to top ]

    I read the book, and have recommended it to friends. And, no offense, but it's not the Bible, just because he says their reason for something was one thing doesn't mean that's _actually_ the reason, or the only reason. It sounds like you're in some sort of consulting business, so I'm sure you've had the experience of justifying a solution to a customer using a rationale that wasn't the entire story, or probably even your original motivation. Serendipity is nice that way.

    Yup. Members of the Spring team have previously claimed that:

    1) A proxy-based AOP framework is fine because most developers will only need interception

    2) Excluding a JSP Tag Library from Spring MVC was an intentional design decision that will somehow make things cleaner

    3) Not being able to perform DI on domain objects is good, because embedding service references into a domain object is always bad design

    Thankfully, the folks at Interface21 show capacity for growth, and they have since recanted all of these positions. Fixes for all three of these problems are scheduled for Spring 2.0.
  74. Spring is more than one thing[ Go to top ]

    Yup. Members of the Spring team have previously claimed that:1) A proxy-based AOP framework is fine because most developers will only need interception2) Excluding a JSP Tag Library from Spring MVC was an intentional design decision that will somehow make things cleaner3) Not being able to perform DI on domain objects is good, because embedding service references into a domain object is always bad designThankfully, the folks at Interface21 show capacity for growth, and they have since recanted all of these positions. Fixes for all three of these problems are scheduled for Spring 2.0.

    Although I can see that 1. & 2. are wrong assumptions, I still believe in 3 ;). Seriosly, could you give me some good example where service reference in a domain object makes more sense then making service manipulate domain object?
  75. Spring is more than one thing[ Go to top ]

    Corby
    Yup. Members of the Spring team have previously claimed that:1) A proxy-based AOP framework is fine because most developers will only need interception 2) Excluding a JSP Tag Library from Spring MVC was an intentional design decision that will somehow make things cleaner 3) Not being able to perform DI on domain objects is good, because embedding service references into a domain object is always bad design. Thankfully, the folks at Interface21 show capacity for growth, and they have since recanted all of these positions. Fixes for all three of these problems are scheduled for Spring 2.0.
    Indeed we are always willing to learn and listen to users. I and other Spring devs spend a lot of time on the Spring forums, for example, looking at what people want and what they have pain with. And of course we see a lot of large Spring projects through Interface21.

    And yes, we do get things wrong :-; But if we're wrong we sincerely want to know and the sooner people tell us the sooner we can put things right :-)

    However, I think our past positions were a little more complex than this on 2 of these 3 issues... Speaking for myself:

    1. I've always clearly stated that I thought that proxy-based AOP had a lot of value, but was far from a total AOP solution. Both I and Adrian see Spring AOP and AspectJ working together to create a total AOP solution that meets the needs of all users. We are enhancing Spring AOP without changing its proxy-based model, through getting access to AspectJ features such as the pointcut expression language and even the annotation-based aspect syntax in AspectJ 5. (Spring 2.0 can process AspectJ annotations such as Aspect, Before and Around.) We are also ensuring that Spring and AspectJ work together seamlessly. But let's face it, for users who want full-featured AOP, AspectJ is the solution, and it would be foolish for us to try to compete with that. So Spring AOP will not aim to become another AspectJ; it will be enhanced to make it the ideal solution for its market niche, and we will ensure that using Spring and AspectJ is a great experience.

    2. Yes, excluding a JSP tag library was an intentional design decision. Continual user requests indicate that we got this one wrong, and as you say we're providing a full-featured tag library in 2.0. (Btw if you're not using JSP, we already have great FreeMarker and Velocity macros.)

    3. I've always been interested in getting away from the "anaemic domain model" problem: it's just that I think it needs to be done cautiously, and that we need to learn as we go. Spring 2.0 will provide a great out of the box solution. Adrian and I are also really looking forward to working with Eric Evans on realising DDD with Spring, perhaps in the form of a reference application. We also need to benefit from user experiences here, and I hope that you and many others will continue to feed back to us in the Spring forums and elsewhere.

    Rgds
    Rod
  76. Spring is more than one thing[ Go to top ]

    I read the book, and have recommended it to friends. And, no offense, but it's not the Bible, just because he says their reason for something was one thing doesn't mean that's _actually_ the reason, or the only reason. It sounds like you're in some sort of consulting business, so I'm sure you've had the experience of justifying a solution to a customer using a rationale that wasn't the entire story, or probably even your original motivation. Serendipity is nice that way.I am perfectly willing to believe that Rod Johnson et al have made a virtue of their 'lightweight' AOP solution, but that doesn't mean they won't add more features to it over time.
    Wrong again. First of all, I'll believe Rod when he says his reasons are this or that over *you* saying that his reasons were this or that. Second, these customers were won because of the solutions I've been advocating *before* I started using Spring. As I've posted before, my boss, when I interviewed said that he wanted a framework to more easily create the kind of webapps we write, to replace the very proprietary code they had in house. I started with Struts, added Hibernate, then brought in Spring.

    We now have code, based on SSH(Struts, Spring, Hibernate) that I use for every project in which I'm involved and I advocate it for projects for which I'm not directly involved. I'm NOT in the habit of misleading customers because that type of behavior will cost customers. What won them over was me being able to say that they have a reusable solution based on very well accepted technology and is easy to support. I've told my boss and her boss that you can fire me and pull developers off the street to use this stuff.

    And this has been proven by direct experience. I don't have to explain web frameworks, persistence, wiring, or AOP. I just point people to the Spring book.

    My original motivation was to develop a framework and I've done so using this excellent technology.

    Now, of course they will add to the framework, but that doesn't affect their original motivations of selecting concentrating on features they considered core.
  77. Spring AOP in Spring 2.0[ Go to top ]

    Spring clearly implemented the low-hanging proxy fruit in their initial AOP implementation.They have hired Adrian Coyler into a prominent position specifically because they want a full featured implementation of Spring AOP ready for release 2.0.

    Let me clarify what we're doing with Spring AOP and AspectJ in the 2.0 release (we went into this in some detail at The Spring Experience conference last week, and will be making more information available on the web very soon).

    * Spring AOP is remaining as a proxy-based framework offering the ability to advise bean method execution. The facilities that Spring AOP offers are complementary to AspectJ in that they offer runtime control of advice on a per-instance basis, for beans managed by the Spring container.

    * The configuration of Spring AOP is dramatically simplified in Spring 2.0 using the new XML schema support. Configuration of transactions is simplified even further. Spring 2.0 remains fully backwards compatible of course.

    * Spring 2.0 adds the ability to use the AspectJ 5 pointcut language when configuring Spring advisors and aspects (you can write an AspectJ pointcut expression directly in the xml file). This still uses the Spring AOP proxy framework (not AspectJ) to implement the advice behaviour, but it uses AspectJ 5 to parse and match the pointcut expressions. This gives Spring users the option to use a powerful and flexible pointcut language (that understands generics, varargs, covariance, annotations, and so on) that works consistently across both Spring and AspectJ. It also means that Spring pointcut expressions can refer to pointcuts in compiled AspectJ libraries when using Spring and AspectJ together.

    * Spring 2.0 adds support for @AspectJ aspects (aspects written using the AspectJ 5 annotations such as @Aspect). If you have an @AspectJ style aspect, Spring can support it using the Spring AOP framework. You then have the choice to seamlessly switch from Spring AOP to AspectJ based weaving if you find you need greater performance or features that go beyond the capabilities of the Spring AOP framework.

    * Spring 2.0 ships with a new jar, spring-aspects.jar, which will contain a number of AspectJ aspects for working with the Spring framework. Use of these is entirely optional of course. The first of these is a "BeanConfigurer" aspect that enables Spring to dependency inject domain objects simply by annotating them with "@Bean" (the annotation is @SpringConfigured in CVS, but we plan on changing the name). We believe the ability to dependency inject domain objects (created using the new operator, or by your ORM mapping tool for example) is a big step forward for folks who want to embrace richer domain models (and from TSE last week, I can tell you that there certainly seem to be a good number of them).

    So in summary, Spring AOP as a framework is not growing beyond its original boundaries. Instead we've simplified the configuration and enabled the use of the AspectJ pointcut language and even @AspectJ aspects. Instead of replacing Spring AOP with AspectJ, or growing the capabilities of Spring AOP beyond its current bounds, we believe in providing a seamless roadmap from using the out-of-the-box Spring aspects (such as the transaction management support), thru writing your own Spring aspects and advisors, and onto AspectJ aspects, without any jarring discontinuities. Thus you can use as little or as much of the capabilities as you need, and as your requirements change there will be a solution available to support you.
  78. If I had a Silver Hammer[ Go to top ]

    Been using the Spring Framework since it was the interface21 framework, and I have nothing but great things to say about it.

    Recent Scenarios where I have avoided Spring were:

    1) Writing a public Toolkit/API - I didn't want to have to require everyone to have to download Spring to distribute and use it. Plus for those who don't currently understand or use Spring it can add to the learning curve and decrease adoption rates (Thats alot of extra downloading and infrastructure for a "middleware" based API...)

    2) Client didnt want it... (They had already reached API overload) Sometimes more framework infrastucture to an already bloated application is a bad idea

    If you consider SpringMVC/WebFlow it's important to note that Rod & Co. decided not to use SpringMVC/WebFlow for SpringFramework.org (they use Drupal... PHP), so for "Adware" like or "Community like" sites, you might be better served with something else (KISS).

    Spring isnt a silver hammer, but I absolutely agree it is great for mid to large J2EE apps it can be very useful.

    My 2cents : Leave Spring separate, I dont belive anything good becomes of bundling, "standardizing" or whathaveyou. I'm still bitter about the debachle where the XML APIs were integrated with the JDK/JVM...Stupid "endorsed dirs"... I mean how much bigger are we going to let the JDK distributeabe become... (It's like a Gig already with Javadocs and source)
  79. If I had a Silver Hammer[ Go to top ]

    Silver Hammer?
    How about a Sledge Bullet!
  80. Utility Functionality[ Go to top ]

    Even if you don't want to drink the AOP/IOC kool-aid (which I have and enjoyed every bit of the Spring flavor, personally), I found that Spring had a lot of "utility"-level features, many of which I always wrote myself (but rarely did as well as the Spring devs). Like the JDBC utilities and 'wrappers'...it seems everyone likes to write their own abstraction utilities, but after a few times it gets very tiresome and it's nice to have in a widely-used framework.

    I'm unsure of the wisdom of suggesting its inclusion in the 'official' spec though; in fact, I hope they don't.
  81. I hate to be saying something different from everyone else, but I love to be proved wrong, . Here are some of my observations.

    I have followed Spring (and Pre-Spring) for a long time. And love the concept of IoC (dependency inject), JDBC callback template and some other values Spring has to offer. I haved used and modified the pre-spring code (from Rod Jonson's 1st book) form the JDBC wrapper framework in one large project (200K lines of code invloves Oracle/DB2/SQLServer and Weblogic/Jboss/WebSphere). It has worked great for us. We recently replaced our EJB 2.1 CMP beans with Hibernate and we used Spring's HibernateTempalte. The template works fine.

    I have not used the core values provided by Spring, BeanFramework: IOC, AOP, POJO based transaction . I have read both books by Rod Johnson, as well as Profession Spring and Spring in Action.

    My current thougt is that I may not use Spring in my next project and here is my thought on this:

    Spring brings a stack of value propersitions, it also introducing something else: file-based XML configuration. Even though this is nothing new, as every other framework does the same, but seems to me Spring has shift the programming model from Java to XML. Instead programming in Java, now you are programming in XML. The balance is now empersize a bit too much on XML configuration.

    IMHO, if the things need to be frequently changed, and reconfiguraed, it is likely this configuration should belong to a database so it can be managed in remote/distributed manner. If the configuration is occuationally changed and be pluggable, it can also be configured via database. The difference is write a SQL (or better yet, using a configuration API), or edit a XML file.

    For IoC, on one side, it seems simple for Spring to inject a service; on the otherside, it also seems getting complicated with so many XML file to manage (correct me if I am wrong).

    As regarding to other value propersations: the new development on EJB3 seems covers that ground as well.

    JBOSS's embedded microkernel with EJB3 seems to allows user to test applications outside the Application server.

    So my inclination is to use EBJ3 (which also provides the transaction management) for Remote Interfaces (SLSB), java persistence API (EJB3 or Hibnerate3 or JDBC Wrapper, -- I haven't decided yet) for persistence, using ApsectJ for the AOP support.

    Again, these just my initial thought and observation. As the choice of technologies and approaches are simply trade-off beteween one and another, I would love someone convice me that there are better trade-offs using Spring than the one I incline to use.

    Chester
  82. Configuration != Wiring[ Go to top ]

    IMHO, if the things need to be frequently changed, and reconfiguraed, it is likely this configuration should belong to a database so it can be managed in remote/distributed manner. If the configuration is occuationally changed and be pluggable, it can also be configured via database. The difference is write a SQL (or better yet, using a configuration API), or edit a XML file.

    I agree 100%. I am not fond of using XML for configuration files. Which is why I like migrating to Spring. I wire some of my components in XML (which IMHO doesn't change that often) and use property placeholders to do my configuration. I put the XML files in my jar files and the configuration in property files on the classpath or use Apache Configuration to store them in the database (using a simple property file for bootstraping the Apache Configuration).

    By having a standard mechanism like a PropertyPlaceholderConfigurer, you separate your configuration from your wiring. And when non-XML methods come along for wiring your application, you can still use the same configuration mechanism.
  83. Configuration != Wiring[ Go to top ]

    Totally out of topic, but I'm really surprised to see someone else with the same last name as me. Are you from Quebec too?
  84. Configuration != Wiring[ Go to top ]

    Just to clarify, when I referring XML configuration, I am referring to both Application Settings (application configurations) as well as component wiring (Component Configuration).

    To me, they are different in certain aspects, but they are also same in other aspects.

    Chester
  85. Configuration != Wiring[ Go to top ]

    Just to clarify, when I referring XML configuration, I am referring to both Application Settings (application configurations) as well as component wiring (Component Configuration). To me, they are different in certain aspects, but they are also same in other aspects.Chester

    Chester,

    Quite a few people have commented they aren't keen on the
    choice of XML-based configuration for Spring (and others). I'd be interested to hear thoughts from yourself and any other contributers to this thread on what could be a better medium?

    XML has some obvious benefits for both configuration and wiring:
    - Standardisation
    - Defines, and yet also restricts in a complementary way, configuration capabilities
    - Can be viewed, edited and validated using industry standard XML editors (XML Spy, Oxygen...)
    - Can be loaded by 3rd party tools and plugins

    I agree that it can become large and unwieldy on large
    projects though.

    Thanks,

    Gary
    __________________________________________________________
  86. Configuration != Wiring[ Go to top ]

    I agree that XML definitly has it's value propersition. What I am worried about the over-use of the XML which bring the managebility issue.

    For small to media project, XML configuration may be fine. For large project, especially large project with RDBMS, I prefer to use database as my configuration store if I can.

    We have developed an simple configuration table schema in database that store application settings that can store key, value pairs, where the value could be single value, or List or Map etc. it works well for us.

    Currently, Spring is using XML as the configuration tool. But from what I can see you can also develop a database based-Configuration and plugged into Spring BeanFactory. That actually will make thing more interesting.

    If One can switch from one configuration format to another, that would even more interesting. As development team can work with the most comfortable format (be it XML or database), and still make it managable in remote/distributed manner.

    my two cents.

    Chester
  87. Configuration != Wiring[ Go to top ]

    Are you talking about wiring? I can't imagine putting Java object relationships into a relational database. I'd rather store them in the source directories where the Java is.

    If you are talking about properties, some type of database configuration is the way to go. Apache Commons Configuration can handle simple properties as well as lists (by expressing them in a single value as a comma separated list, which Spring will convert) To handle maps you'd need something custom like you've developed.
  88. Configuration != Wiring[ Go to top ]

    The XML in my current project is out of control, and a few developers on the team are starting to complain about it. This is the only part of spring that bugs me.

    I know the xml is fine in most cases, but in big projects it kind of sucks.
  89. Don't look from developers angle only[ Go to top ]

    J2EE environment is not for micky mouse types of applications. We all know what is the main intention of J2EE.

    Usually one of these applications have a development lifecycle of about 12 months, and production life of about 5 years.

    As an architect you have to look at your design from different perspectives.

    Maintenance is one of these. If you are developing a mission critical application where whole company's future is at stake, would you use Spring in it. Couple of years down the track, if interface 21 goes bust or I can't find developers who want to work with old technology like spring as everyone has moved on to EJB3 or something similar, and my application breaks for certain reason, where will I get support or resource to maintain my application?

    These are the questions, which make me wonder what types of applications people are developing and using spring in it.

    I have real experience with frameworks when everyone moved to different technology and we eventually had to rewrite in different language all together.

    I would like to stick with J2EE blue prints, may be it takes bit longer to develop but it does not introduce dependency on "open source" products in mission critical applications.

    So guys, don't be just developers and look at convenience, look at your code from maintenance point of view also.

    Cheers

    Gurvijay Singh Bhatti
    Sydney Australia
  90. Couple of years down the track, if interface 21 goes bust or I can't find developers who want to work with old technology like spring as everyone has moved on to EJB3 or something similar, and my application breaks for certain reason, where will I get support or resource to maintain my application?These are the questions, which make me wonder what types of applications people are developing and using spring in it.
    You can apply this sort of reasoning on any kind of product, not only open-source. Imagine if Sun should close its business for example, or if everybody jumps into the-next-big-thing and leave java behind, would we say goodbye to J2EE and all? Or would other companies take over its maintenance, maybe even open-source community?
    Open-source is a relatively recent way of dealing with software development, compared with traditional closed-source one, but both have their intrinsic risks of failure and going out of market. Some even argue open-source is less risky, since anyone has access to source code, contrary to closed-source software. Plus, open-source companies usually are a by-product of a successful project in the first place, with a stablished community around it, not the other way around, so even in case open-source companies go down, it doesn't mean the original open-source project or its community should go down with it too, both are somewhat independent in most cases, as nothing should impede community to take over project control and development, if enough interest exists.
  91. I agree that there is support from the community, but I can't wait for the community to fix a bug against a SLA.

    Which manager will trust on community to fix an application without any SLA when the whole business depends upon it.

    We have to be realistic, put yourself in the architect's shoes who is designing a system that is maintainable and have got SLA's in place for all the components, hardware, app servers, database etc etc; except the main business tier depends upon community to support.

    Will you be able to sell open source to your management?

    Cheers

    Gurvijay Singh Bhatti
    Sydney Australia
  92. Don't look from developers angle only[ Go to top ]

    Already done.

    Last year we were developping a security component wich was plugged in the applications by using the standard J2EE container security (by the way security really sucks in J2EE, really need some work).

    While doing some testing, we stumbled upon a critical bug that was coming from the commercial J2EE container (wich I won't give the name). We contacted support and they acknowleged it was definetly a bug. You can guess that application security infrastructure qualify as a mission critical component. So couple of weeks later we ask for an ETA and they answer they can't give any details since it is a security issue..... I hate this politic. So one month later, since we didn't have any news, we took the decision to plug-in the security using a custom solution instead of the container security. We haven't received any news about the bug yet and we placed the call 3 months ago. So commercial products don't guarantee necessarily service. Anyway there are plenty of discussions about open source vs commercial solutions, we use both for the moment and I must say I prefer open source solutions because of all the community around them that can provide help.
  93. Don't look from developers angle only[ Go to top ]

    Couple of years down the track, if interface 21 goes bust or I can't find developers who want to work with old technology like spring as everyone has moved on to EJB3 or something similar, and my application breaks for certain reason, where will I get support or resource to maintain my application?

    You just need to implement Spring wrapper to solve this problem. If you want to be more safe then you can wrapp your wrapper to add abstraction layer using best practices. It is not a reason NOT to use Spring ;)
  94. old technology like spring? come oooon.What about struts? it's been around for 5 years or so. Compared to it, spring is last generation technology. i think every developer should go through the spring experience, because they have a lot to learn, so i think you'll find developers fond of spring to work with even in that metaphorical world of "ejb3.0 is the only solution" :)
  95. Don't look from developers angle only[ Go to top ]

    J2EE environment is not for micky mouse types of applications. We all know what is the main intention of J2EE.Usually one of these applications have a development lifecycle of about 12 months, and production life of about 5 years.As an architect you have to look at your design from different perspectives.Maintenance is one of these. If you are developing a mission critical application where whole company's future is at stake, would you use Spring in it.
    Maintainability concerns are one of the primary reasons that drove Spring's creation. Note also that Spring 2.0 will be wholly backward compatible, a huge plus for enterprise class users.

    Spring's strengths are actually greatest in more complex applications. Many companies are using Spring in mission-critical applications. So far we've done a relatively poor job of chasing public references, but this is going to change in the very near future. We'll be publishing numerous case studies in the next few weeks and months. Some notes to start with:
    - Interface21's clients (by revenue) are mainly in the banking sector. Obviously I can't name names (although you can email me offline, my address isn't hard to find), but we are providing a range of Spring services, including 100-500 annual training seats, to 2 of the world's top 5 banks, and also deal with at least 3 global top ten investment banks. All of these multi billion dollar organizations are making Spring a strategic choice across many projects, not just using it here and there.
    - A core part of the UK domestic banking sector is already live on Spring, with more due to roll out next year, replacing a mainframe system
    - The European Patent Office has been using Spring 1.0 since its release. They are delighted with full-stack usage of Spring, and are currently handling 34 million page views per day, with stringent security and reliability requirements, on behalf of 29 member states. We are planning
    - At the recent Spring Experience conference in Miami, Thomas van de Velde of Accenture described how his team has developed the French online tax submission system (dealing with around 30m French taxpayers) using Spring. Most of this is now live, and the rollout is completed in February 2006. The application has excellent performance and reliability characteristics.
    - There were several other case studies at the Spring Experience, including one from eBay, Dekabank (a major German bank) and Symantec.
    - Two of the world's largest consumer electronics firms have made a strategic choice to use Spring in internal case management systems and high-volume customer-facing web sites.
    - Spring has extensive use in Government around the world(including in Australia, with one pretty central institution--again, feel free to email me). Currently one of the world's largest SIs is doing their biggest ever Java project for a prominent US government agency, and it's based on Spring. And the results are excellent.
    - At least two domain name registries build many of their apps on Spring.

    This is just scratching the surface. So in short--if you live in the UK or France, you're going to interact with a Spring-based app very soon, if you haven't done so already. If you interact directly with an investment bank, the chances are pretty good Spring will be in the mix.
    Couple of years down the track, if interface 21 goes bust or I can't find developers who want to work with old technology like spring as everyone has moved on to EJB3 or something similar, and my application breaks for certain reason, where will I get support or resource to maintain my application?These are the questions, which make me wonder what types of applications people are developing and using spring in it.
    BEA have already committed to support Spring to their customers. While they have chosen to do that in partnership with Interface21 (and clearly feel pretty convinced of our long-term viability), they are making a serious commitment to their clients here: regular 5 + 2 support. They clearly
    - see Spring sticking around for many years
    - see many of their key customers making a long-term commitment to Spring

    Btw BEA have announced that their upcoming WebLogic RealTime server product (aimed at demanding areas such as front office banking, where Java have not yet made much headway) will base its programming model on Spring.

    We also expect to build partnerships with other leading companies in the Java/J2EE space. And remember that Spring is very well commented and a pretty clean piece of code--plus it's Apache License. Many large enterprises feel very good that they don't require an escrow agreement, as in the worst case they have the source.

    And Spring adoption is growing apace; last year it decisively crossed from early adopter to mainstream usage, and enterprise usage is growing strongly. Again, you don't need to take my word for this; we'll be making a lot more references public soon, and I'm happy to reply to enquiries off line.

    With Spring 2.0, we are moving forward rapidly, and making Spring an even more compelling choice to existing and new users. We don't expect that Spring will be "old technology" any time soon :-)

    Rgds
    Rod
  96. Don't look from developers angle only[ Go to top ]

    Could you provide a link to the upcoming features in Spring 2.0?
  97. Don't look from developers angle only[ Go to top ]

    Thanks Rod for your email,

    Another criteria for my architectural evaluation is "Evolution". I see some bright future of 3.0 specifications and see lots of goodies from different frameworks incorporated in there.

    As David asked, could you provide us with some information, so that we can judge Spring based on Evolution criteria.

    Thanks and regards

    Gurvijay Singh Bhatti
    Sydney Australia
  98. Don't look from developers angle only[ Go to top ]

    Could you provide a link to the upcoming features in Spring 2.0?
    We will be uploading some of the presentations from the Spring Experience and JavaPolis to springframework.org early next week. Our conference commitments have been intense in the last 2 weeks...

    In the meantime, there should be some material on JavaLobby, which covered TSE.

    Rgds
    Rod
  99. Features in 2.0[ Go to top ]

    David
    Could you provide a link to the upcoming features in Spring 2.0?
    As I promised, we'll try to get some presentation material up ASAP. But in the meantime, I thought I should put something here. The biggest new features include:

    - A schema-based XML extension mechanism for configuration. It's possible to define new XML tags (with an accompanying Java class) that emit one or more Spring bean definitions, or decorate existing bean definitions. This makes common tasks easier (for example, JNDI lookups, referencing properties files) and benefits from tool support. (Code assist comes for free in any environment.) We'll be shipping many out-of-the-box tags, and it will also be possible for power users and developers of third-party products that integrate with Spring to implement their own. The configuration mechanism is wholly backward compatible. Bottom line: more concise configuration for repeated tasks, with better tool support.

    - Integration with AspectJ. I'm particularly excited about this, and it's been great working with Adrian Colyer on these features. It's now possible to use the AspectJ pointcut expression language to target Spring AOP advice in XML or other configuration, or programmatically. Spring AOP can automatically recognize and apply AspectJ 5 annotation-syntax aspects, also. (Only method execution join points are supported, but that still represents a huge amount of value. Essentially the full expressive capability of AspectJ pointcuts is available, including composition of pointcuts, reusing named pointcuts etc.)

    Note that we're talking about improving Spring AOP here, and that all these features are available in Spring AOP's proxy-based runtime model. However, there are also features for AspectJ users who wish to use Spring, or Spring users who are interested in AspectJ itself, such as an AspectJ aspect that can dependency inject any object using Spring, regardless of whether it was instantiated by Spring; and an AspectJ transaction aspect. (Of course, Spring has supported dependency injection of AspectJ aspects since 1.1.)

    Other features include:

    - Message-driven POJO support, including acknowledgement in tx
    - Support for additional bean lifecycle scopes such as per HTTP session. (The impelmentation allows for pluggability, as we see that this feature can be useful not only in web applications.)
    - Integration with CommonJ APIs such as WorkManager
    - Portlet MVC framework
    - Asynchronous task execution framework

    In 2.0M2 we'll be adding:

    - Ability to define a Spring bean where the implementation is written in a language other than Java, such as Groovy, but which still runs on the JVM.
    - Ease-of-use enhancements in Spring MVC such as improved tag libraries and code-by-convention defaults.

    I'm sure I'll get an email from one of the other Spring devs shortly complaining about features I've left out; the list is longer than this, and there's lots of good stuff.

    And, of course, it's all 100% backward compatible :-)

    Rgds
    Rod
  100. I think it would be nice if the JDK picked up some of Spring's little things, for example InputStreamSource. The JDK could really do with a standard factory interface for InputStreams -- it enables a much nicer style of programming and resource management with them.

    We have a home-grown InputStreamTemplate that provides a closure-style of programming with InputStreams analagous to JdbcTemplate with DataSource. It would be better for this sort of thing if the interface dependency were on the JDK rather than Spring.

    Regards

    John Hurst
    Wellington, New Zealand
  101. People, it's just a framework![ Go to top ]

    I have researched Spring many times and while I find it to be interesting, I am curious on to why it is treated like a Golden Hammer. I found Spring to have XML configuration files just like EJB. While you didn't have to deal with as many source files as you did with EJB, using interfaces and inheritance made the creation of the additional source files a minute or two.

    In the end, I find Spring a nice way to get people started in AOP/IoC coding that haven't done it before. Can you do these things without Spring? HELL YES. I did so several years ago and was able to convert a Struts app to do entity persistance from Entity Beans to Hibernate in a week. I was even able to have both persistance mechanisms running at the same time.

    If you want to do IoC/AOP and haven't done it before, then Spring is a way to jumpstart this process. Just like when you wanted to start doing MVC, you used Struts.

    Just remember that these things are frameworks. If they don't do everything that you want it to, extend it or contribute to it! Shale and Beehive are extensions to Struts. Are there extensions to Spring?

    John Murray
    Sobetech
  102. People, it's just a framework![ Go to top ]

    Shale and Beehive are extensions to Struts. Are there extensions to Spring?John MurraySobetech

    I would agree that Shale is a subproject of Struts but not an extension at all. It has been stated several times that the code base is totally new. They are part of Struts so they can share the community.

    The framework is built around JSF. I am using it right now to build my first JSF application and there's nothing from classic Struts.
  103. People, it's just a framework![ Go to top ]

    I would agree that Shale is a subproject of Struts but not an extension at all. It has been stated several times that the code base is totally new. They are part of Struts so they can share the community.The framework is built around JSF. I am using it right now to build my first JSF application and there's nothing from classic Struts.

    Sorry about that, my bad.
  104. This is a silly question[ Go to top ]

    I've started building J2EE Applications in 2000. I started to use Spring when I stumbled over AppFuse early this year (nobody has given Matt Raible credit for his great work so far in this Thread!!!). I never thought I would need such a itsibitsi IoC Framework like Spring, but I'm a bloody convert by now.

    My actual client has got a huge J2EE eBusiness CRM application with all bells and whistles (about 4K classes) and I see, that about half of it is just infrastructure code, code to get around deficiencies of J2EE (don't spawn a thread, don't listen to a port, etc.) and what for? The app runs on 16 Processors on 4 Fire 440 and is not clustered but does load-balancing and failover via a hardware loadbalancer (They don't care about session failover as long as the app is reachable). My opinion is, that in this case J2EE (In fact I mean EJB container...) is nothing more than a roadblocker.

    Don't get me wrong, there are cases, where J2EE (EJB container) is of great help, but I doubt that more than 10..20% of the "J2EE Apps" really have any benefit from it. (Always referring to EJB2.1)

    Spring on the other hand just makes things wonderfully easy. Yes, you can do everything in java building your own singletons (have you done the synchronization right?) your own factories (I hope you've got a good configuration system for them?), but when I work on an application I want to concentrate on the business logic and not on how I get from here to there (Infrastructure).

    If you want my 2cents, try hard to find reasons **not** to use Spring (or Nano-Container, or Beehive, or another appropriate IoC framework... ) even inside an EJB container.

    ------

    And I can't hold back... Everyone programming his own JDBC Framework or doing JDBC inside his Application just has not had his reality check. Sorry, this doesn't include projects without foreign keys :-) It's just waste of (expensive) time, because you can't get faster, or simpler, or more clever than the creators of Hibernate/Kodo/JbossCMP/iBatis etc.
    And the people doing the xml-mapping for these frameworks by hand seem to never have heard of xdoclet -- for a really good example of how the various components can play together, please please please save yourself much time and hassle and have a look on AppFuse.
  105. Hivemind ... anybody ?[ Go to top ]

    Old discussion, I know, but I would really like to have some opinions about Hivemind vs. Spring. I took a look at Spring and got really suspicious of a framework which claims to be non-invasive as everything is POJO, everything is a "can" not a "must" and so on. Hivemind looks very clean to me, nothing less but also nothing more than a nice IoC-Container. Spring has this massive approach of making abstractions for nearly every well-known tool and framework.

    But is it still lightweight nowadays ? Does anybody have problems using Spring ? I mean, perhaps I'm too sceptical (which is due to my experiences) but this mega-hype for this meta-framework seems a little bit oversized, doesn't it ? I still don't believe that the silver bullet exists :-)
  106. Hivemind ... anybody ?[ Go to top ]

    Hi,

    I haven't actually tried to develop anything using HiveMind myself yet (maybe I should...), but I have tried to understand and customize Tapestry 4 configuration with HiveMind.

    I hope it's just me, and that I'll get over it, but so far I have found HiveMind configuration of Tapestry a complete nightmare to understand. There are so many files, with so many weird looking entries -- it just seems really overdone. Every couple of weeks I get bored enough to try to find out how to inject the HttpServletRequest into one of my service objects using HiveMind -- it must be possible! But I fail, and go back to using the deprecated RequestContext API.

    Spring has always been both powerful and completely intuitive for me. Spring configuration files are completely straightforward to read and understand.

    I don't doubt that HiveMind is well-designed and a good thing for Tapestry. But so far I am finding it a struggle. Then again, Tapestry is a pretty complex beast.

    John Hurst
    Wellington, New Zealand
  107. Hivemind ... anybody ?[ Go to top ]

    It depends on what you mean by "lightweight". Some of Springs features like the IOC and transaction management can be done without relying on any Spring defined interfaces or base classes. Others like aop and the Web/MVC stuff require it. But those types of features always require that.

    Find me an aop library that doesn't require that you use some type interface or base class. The same for a web framework. I will say that the Spring web/mvc is a lot less dependent on proprietary interfaces/classes than struts. In Spring the domain object is a plain pojo. In struts is a subclass of an actionform. In the spring controller classes have to implement a interface (although a lot of functionality is provided through base classes). In struts the controller must always be a subclass of an ActionController or its related classes. Buts thats just comparing it to struts.

    Lots of people seem to have problems with the hibernate template for some reason. While it does provide some benefits, its certainly not requried. There is nothing stopping people from writing straight hibernate API based code and having their sessionFactory provided by depency injection. In fact its perfectly possible to combine both approaches in the same application. The hibernate template is a convienence.

    I can see the appeal of using just a straight IoC container framework. But I think the added benefits of using aop really tip the scales in favor of struts. Its not that I think a lot of application code needs aop. Its just that its presense in the framework allows Spring to provide a lot of its benefits (like declarative transaction management) in a completely non-invasive way.
  108. Hivemind ... anybody ?[ Go to top ]

    Old discussion, I know, but I would really like to have some opinions about Hivemind vs. Spring. I took a look at Spring and got really suspicious of a framework which claims to be non-invasive as everything is POJO, everything is a "can" not a "must" and so on. Hivemind looks very clean to me, nothing less but also nothing more than a nice IoC-Container. Spring has this massive approach of making abstractions for nearly every well-known tool and framework.But is it still lightweight nowadays ? Does anybody have problems using Spring ? I mean, perhaps I'm too sceptical (which is due to my experiences) but this mega-hype for this meta-framework seems a little bit oversized, doesn't it ? I still don't believe that the silver bullet exists :-)

    We've had no problems. We are up to 6 projects and 1.5 years of using Spring. It works and as we've grown, it has allowed new people to ramp up very quickly *because* I don't have to sit and explain much in-house code. The design, IMO, is very clean and has proven very scalable. In addtion, we've won business because we could say we are using this code that has been testing on previous projects. Spring creates the paradox of being "cutting edge" and "safe" at the sime time. I've moved the code base from Oracle9iAS, JRun4, and Tomcat almost seamlessly and this just has not happened with EJBs. We are in the middle of finishing a project and had some performance issues(not Spring or framework related) and I was able to add a simple ProfileInterceptor and about a hour that affects all of the desired intefaces in our middle-tier.

    Another guy was able to use Spring to easily use our middle tier(all POJOs) to make standalone application and of course uses all the same stuff that our web app uses. Total reuse for a web and standalone application easily acheived. I use Spring for configuration, AOP-enhanced functions( security, transactions, profiling,and caching), Hibernate integration, and email support. Soon, I'll be adding messaging for async-calls to our framework and all these services are pojo-based and interfaced driven.

    You could do this without Spring, but Spring makes it easy to do. Heck, with Spring, just about every interface has an object injected in that makes the system configuration available.

    It just promotes clean design and I don't have any issues with the XML configuration. Give the files a good name and separate the concerns correctly and people can navigate them.

    I think the hype is justified.
  109. Alef's Demo[ Go to top ]

    I was at the Spring Experience, and enjoyed myself immensely.

    I was at Alef's demo, and I think I saw him do what Matt's blog entry describes. However, the way it went, there was so much copying of this and that, here and there, with a couple of consoles going, etc., and *no* difference in the final result, that he could simply have been running smoke and mirrors on us. Not saying he was, understand, just that it was a very dynamic demo with no observable difference in the result. Which opens a door for cynics like me.

    I believe it was an honest demo, which definitely confirms to me the value, not just of Spring, but of the team that supports it.
  110. Alef's Demo[ Go to top ]

    Patrick
    I was at Alef's demo, and I think I saw him do what Matt's blog entry describes. However, the way it went, there was so much copying of this and that, here and there, with a couple of consoles going, etc., and *no* difference in the final result, that he could simply have been running smoke and mirrors on us. Not saying he was, understand, just that it was a very dynamic demo with no observable difference in the result. Which opens a door for cynics like me.

    I believe it was an honest demo, which definitely confirms to me the value, not just of Spring, but of the team that supports it.
    It was a 100% real demo. You can try yourself from CVS. The drop in part will work with the 1.2.6 jPetStore, and Alef has committed the new version of the XML file to CVS.

    What's more when we first had the idea of doing the drop in replacement demo, no one in the room (all core Spring devs) had the slightest doubt that it would going to work...

    Yes, Alef does work at a very rapid pace... He's just like that :-; Clients love it.

    Rgds
    Rod
  111. I take your point[ Go to top ]

    I take your point. I'll reiterate: I enjoyed the conference thoroughly, and I believe it was an honest demo. I think it shows the value of Spring and your team. Thanks for an awesome framework, and great customer focus.
  112. Forget J2EE[ Go to top ]

    Thesedays I can't develop _any Java_ application without Spring. Not only that - I have recently been working on a .Net/Java integration project. And guess what was the first thing I went to download after installing Visual Studio? Spring.Net!
  113. Forget J2EE[ Go to top ]

    Thesedays I can't develop _any Java_ application without Spring.

    I totally agree. I get concerned where I hear about including Spring-like features in JEE. Things like dependency injection and AOP can be useful in client-side programs too. Spring features should become standard in J2SE.
  114. I don't like spring a little[ Go to top ]

    I must write a lot of configure in the spring.
  115. Spring is good[ Go to top ]

    I use Spring for my J2EE application one year ago. Spring is wery good but I only use IOC of Spring. My best choise is Spring intergated with Struts for presentation and Hibernate for persistent because MVC of Spring isn't very good.
  116. This post is already long, but here are my experiences with Spring.

    A couple of months back, I wanted to reduce custom code in my my non-web application and so, converted to Spring for the following reasons.

    1. We already use Hibernate and a bunch of other packages supported out-of-the-box by Spring.
    2. The templates reduced the code significantly. I was able to replace my own custom transaction management wrapper with Spring's AOP-based transactions with very little effort.
    3. Exception handling in AOP proxies removed a lot of try-catch blocks and throws declarations in the code.
    4. My application was a standalone, non-web application. Spring gave me all the features of a J2EE container without having the need to get tied to an app server.
    5. Even though declarations are in XML, I am fine with it as it is mostly glue code, not business logic. I see this as a clean separation of concern.
    6. When I added MQ and Mail support, Spring already had templates for both, which I think reduces more custom wrapper code.
    7. A few other related projects are web-based that depend on some common libraries, and guess what - Spring has support for Struts and other web frameworks.
    8. We also have a few thick-client applications (deployed through Webstart) and Spring RCP looks quite promising in this area.

    In short, I think Spring nicely caters to non-web, web, and thick-client applications equally. This, to me, is the biggest value-add for a framework along with the fact that they don't reinvent the wheel (well, even if they do, they provide options for others).
  117. I still don't get why there is a need to Abstract out an abtraction layer ? I agree that there are things that Spring is good and benifical at... but abstracting out things like Hibernate further complicate things with no real added benefit. IMO

    I realize that there are a lot of people who have posted on this topic and drank the Kool-aide and believe that Spring is the end-all be-all to every programming problem, but it isn't.

    Yes, there are parts of the framework, especially the core IoC stuff, that are great, but it's not the answer to everything.
  118. I still don't get why there is a need to Abstract out an abtraction layer ? I agree that there are things that Spring is good and benifical at... but abstracting out things like Hibernate further complicate things with no real added benefit. IMO I realize that there are a lot of people who have posted on this topic and drank the Kool-aide and believe that Spring is the end-all be-all to every programming problem, but it isn't. Yes, there are parts of the framework, especially the core IoC stuff, that are great, but it's not the answer to everything.

    I don't agree. Until very recently hibernate hasn't convinient
    transaction handling and session handling. Moreover until HB 3.0 there were checked exceptions in HB. Even now spring has very valuable properties hibernate dosen't have - for example
    declarative transaction management (via AOP). Having all that You can:

    1. Mix Your JDBC/HB/TopLink/JDO/iBatis/Whatever DAOs having consistent transaction management and exception handling. This *is* vaer good, especially in the case of HB, where You are sometimes slighty limited (for example using stored procedures). Having all above You just switch from HB to JDBC DAO by inheriting from other helper class. It's as simple as this.
    2. You can easy propagate Your transactions that span few methods - just like in EJB but on POJO. Try this with pure HB.

    Artur
  119. I still don't get why there is a need to Abstract out an abtraction layer ? I agree that there are things that Spring is good and benifical at... but abstracting out things like Hibernate further complicate things with no real added benefit. IMO I realize that there are a lot of people who have posted on this topic and drank the Kool-aide and believe that Spring is the end-all be-all to every programming problem, but it isn't. Yes, there are parts of the framework, especially the core IoC stuff, that are great, but it's not the answer to everything.

    Here is the problem. It's not that you don't see, it's that you haven'y *used*. And I defy you to find a single post where anyone said Spring is great for everything.

    That's nonsense mostly spouted by people who have little to know experience with Spring therefore don't understand what it can or can't do. I suspect that anyone who has direct experience with Hibernate and Spring's Hibernate templates would be hard pressed to argue that Spring doesn't reduce the clutter in the code.

    The problem is that it is hard to understand something you've little experience with.
  120. To make your life easier: Use AndroMDA with or without Spring ;-) There you can see that *still* you can optimize Spring by using code generation.

    Check out AndroMDA tutorial with Spring:
    http://www.andromda.org/andromda-spring-cartridge/howto1.html

    If you don't like Spring just use pure EJB with AndroMDA.
    Here is the modeling intro for general AndroMDA use:
    http://www.andromda.org/modeling.html

    So, choose your "plumbing" frameworks (Spring or EJB) as you like and abstract from them by using AndroMDA.

    Cheers,
    Lofi.
  121. Use AndroMDA WITH or WITHOUT Spring[ Go to top ]

    This are like shots to darkness. People don't know that MDD/MDA isn't same old technology which force you to "develop in UML". Everybody tried "develop with UML" 3-5 years ago with no success and nobody is willing to give it new chance.
    However we have also very long way in MDA world. More sophisticated and standardised tools for applying changes in transformation process are necessary. Looking forward for this promissing technology. We are applying MDA rules in software development since 1997 with great success, even before we know that it's called MDA ;-).
    Happy (Andro)MDA user
  122. Jdon is a IOC/AOP framework too, and includes a lightweight Ioc container based on Picocontainer.its special point is that all components are replaceable, even includes the framework itself. you can plug in any java objects, Jdon is a embeddable framework.

    Jdon giving a domain driven development way for data CRUD and batch query (master-details)

    Jdon = Ioc(Pico) + AOP (simple) + CRUD + Cache. it is opensource software too.

    https://jdon.dev.java.net/
  123. I'm considering Spring for a new project, mainly for IoC and a little AOP.

    It certainly is a lot more mature than JEE5, but last time I had a look, the XML was putting me off. I think XDoclet annotations was an option back then, but won't add yet another dependency..

    I've checked google and had a quick look at the Spring site, but couldn't find anything conclusive.

    If there's no support for 1.5 annotations, nor included in one of the coming releases, what are my alternatives? Download Glassfish and get a head start with JEE5,,? ;)
  124. Re:[ Go to top ]

    I've used Spring for:

    * IoC / Dependency Injection
    * DAO Templates (Hibernate, Unchecked Exceptions)
    * Transaction Management (Interceptors)
    * MVC (Just the page flow)

    I plan to carry on with the testing and security modules next.

    It wasn't easy to understand but once you do it works like a charm. Robust code that follows well defined patterns. I wouldn't consider going back ever.

    JoSE
    ====
  125. Compared with the other current frameworks Spring is fantastic. Does the job, has market presence (in the jobs market).

    But there are many times when writing software when there is no need of a framework. Or dynamic runtime xml config with introspection aop tdd etc etc.

    Writing a simple util to mine blobs and interpret them from the db? JDBC is really simple. Property files, remember them, very simple indeed. It's fun to leave the baggage behind.

    Writing long lived services which experiment with EJB3 persistence. Why clutter the solution with legacy frameworks...

    I guess I'm saying, that when doing robust professional development for my daily bread spring is state of the art. But the art in java land moves on quickly, and JBoss Hibernate are still in the game, EJB3 containers with statefull and stateless and MDB and POJO like persistence will rise again. If only they would rename it, and drop JNDI.

    Spring helped kill off an entire generation of frameworks, and, at some point it will go the way of the dodo - it is in the nature of JavaLand for everything to change every 2 years (so far).

    IMHO.

    Jonathan
  126. EJB3 containers with statefull and stateless and MDB and POJO like persistence will rise again. If only they would rename it, and drop JNDI.

    FWIW, it's entirely possible to write an EJB3/JPA app and never use a single JNDI call -- in fact, you'd have to go out of your way to do otherwise. Everything you used to look up in JNDI can now be handled via resource injection. Injection can be performed through XML directives (similar to Spring) or through JavaSE5 annotations in the source code.

    [JPA = Java Persistence API, the spec that defines the POJO persistence model for JavaEE5]
  127. I'm only starting to swim in the EJB3 persistance land... Looks V V good so far. Not sure about some of the config standards yet.

    Also, stateless EJB's are actually a pretty good way to decouple services (if that is what is needed), and that means you are back into app server land and they seem to all be clinging to JNDI - or rather the spec is. Also, in app server land things like the entity manager datasources seems to be injected via a jndi lookup. But as I said, I'm only starting into ejb3 persistence, and I'm more than willing to give up on stateless session beans and remain with soap servers instead.

    Jonathan
  128. I'm only starting to swim in the EJB3 persistance land... Looks V V good so far. Not sure about some of the config standards yet.Also, stateless EJB's are actually a pretty good way to decouple services (if that is what is needed), and that means you are back into app server land and they seem to all be clinging to JNDI - or rather the spec is. Also, in app server land things like the entity manager datasources seems to be injected via a jndi lookup.

    Strictly speaking, EJB3 has nothing to do with persistence. All the new Hibernate- and TopLink-style POJO persistence features were moved to their own spec (around the beginning of 2005) called Java Persistence API 1.0, or JPA. The new features in EJB3 are all about:

    • POJO session beans (meaning your class does not implement anything other than your business interface, or even no interface). No EJB framework interfaces, and thus no need to be in "app server land."
    • IoC resource injection, which eliminates basically all JNDI usage. Specifically, the JPA EntityManager and datasources are injectable just like any other resource.
    • A very robust and flexible interceptor and callback model.
    • And of course, getting rid of XML deployment descriptors (unless you want to use them).

    Along with the above, you get the new "POJO entity" model introduced by JPA...but there's plenty of cool stuff in EJB3 even just from a business logic packaging standpoint.

    Randy
  129. Hi Randy,

    That is very helpful. JPA - I have been reading the spec and yet was still seeing it as EJB3 presistance - i.e. it's the really big news that differentiates EJB3 from EJB2.

    You should post up an article - removing FUD on EJB3. Or something. We need more people screaming about JPA, especially on the server side, and maybe we can turn attention away from ejb3 and towards jpa - rather than let Gavin King grab all the headlines because people aren't scared of Hibernate anymore. But they are scared of EJB/J2EE branding.

    Anyway, thanks.

    Jonathan
  130. We need more people screaming about JPA, especially on the server side, and maybe we can turn attention away from ejb3 and towards jpa - rather than let Gavin King grab all the headlines because people aren't scared of Hibernate anymore. But they are scared of EJB/J2EE branding.

    Well, that's an interesting view. The customers I encounter aren't so much scared of EJB as they are unsatisfied with Entity Beans as a persistence model. We have tons of customers using session beans and they're generally quite happy with them, though of course they're looking forward to the session bean enhancements in EJB3. Some of these customers have looked at Spring, but after looking at EJB3 and finding that it provides basically the same functionality, they elected to stay with JavaEE because they want a multi-vendor impl. So I'm all for getting more attention on both EJB3 and JPA. Clearly the customers who have been dissatisfied with Entity Beans will be looking at JPA. More generally, I expect that many enterprises currently using Spring and Hibernate will look seriously at EJB3 and JPA. Choice is good.

    BTW, JPA != Hibernate of course. The people who were scared (for whatever reason) of "Hibernate" will still be scared perhaps...they now just have the ability to get essentially the same benefits (plus more) by using JPA, and no longer be scared. :)

    Randy (IBM)
  131. It is quite interesting that IBM (or at least some IBMers) become(s) the latest advocate of EJB3 and JPA. With the slower release timeframe of WebSpere servers (compared to its competeters) and IBM's customers reluctance to (always) jump onto the latest release quickly, it should make more business sense for IBM to support Spring (Spring runs on WebSphere 4 as well!).
  132. It is quite interesting that IBM (or at least some IBMers) become(s) the latest advocate of EJB3 and JPA.

    George,
    IBM has always been an advocate of EJB3 and JPA. We are members of the JSR 220 expert group and have been heavily involved in the production of the specs. So I don't understand your comment.

    Randy
  133. ... they elected to stay with JavaEE because they want a multi-vendor impl

    Are you looking at Spring as an alternative to the J2EE container (or just Session beans).

    Please elaborate, this argument doesn't make much sense to me.
  134. Randy
    We have tons of customers using session beans and they're generally quite happy with them, though of course they're looking forward to the session bean enhancements in EJB3. Some of these customers have looked at Spring, but after looking at EJB3 and finding that it provides basically the same functionality, they elected to stay with JavaEE because they want a multi-vendor impl.
    There is absolutely no conflict between Spring and JavaEE. There are significant enterprises using Spring on all production versions of WebSphere, for example. (Including some of IBM's largest customers.) Spring plays nicely with all current app servers, and using Spring does not require anyone to abandon J(2)EE.

    It's surprising that this misconception has lingered for so long.

    Of course there is some overlap between EJB (any version) and Spring. But the statement that "EJB3...provides basically the same functionality as Spring" is highly questionable. For example, EJB3 (besides the persistence stuff, which we're excited about), provides a small subset of the dependency injection capabilities that Spring has had since 2003. It also provides only a very basic interception capability.

    And anyway, EJB3 and Spring are not mutually exclusive. Choosing to use Spring does not prevent anyone from choosing to use EJB3 in future. In fact, WebSphere users in particular would seem unwise to start any new projects making heavy use of current EJB technology, given that EJB3 has a lot more in common in many respects with Spring than it does with EJB2. And AFAIK there is still no timetable when WebSphere users can expect to be able to use EJB3.

    Rgds
    Rod
  135. There is absolutely no conflict between Spring and JavaEE. There are significant enterprises using Spring on all production versions of WebSphere, for example. (Including some of IBM's largest customers.) Spring plays nicely with all current app servers, and using Spring does not require anyone to abandon J(2)EE.It's surprising that this misconception has lingered for so long.Of course there is some overlap between EJB (any version) and Spring. But the statement that "EJB3...provides basically the same functionality as Spring" is highly questionable. For example, EJB3 (besides the persistence stuff, which we're excited about), provides a small subset of the dependency injection capabilities that Spring has had since 2003. It also provides only a very basic interception capability.And anyway, EJB3 and Spring are not mutually exclusive. Choosing to use Spring does not prevent anyone from choosing to use EJB3 in future. In fact, WebSphere users in particular would seem unwise to start any new projects making heavy use of current EJB technology, given that EJB3 has a lot more in common in many respects with Spring than it does with EJB2. And AFAIK there is still no timetable when WebSphere users can expect to be able to use EJB3.RgdsRod

    Rod

    I don't believe I ever said there was a conflict between Spring and JavaEE. I said that after looking a Spring, some customers decided to stay with JavaEE. Perhaps I should have said they decided to stay with just JavaEE rather than mixing in Spring.

    WebSphere users have no problem choosing to use current EJB technology. Like I said, some are unsatisfied with the current 1.x and 2.x EntityBean persistence models (though of course that's not unique to WAS customers!), and are anxious to take a look at JPA as a possible alternative. In any case, the EJB2 session bean model is easily upward-compatible with the EJB3 model so that's certainly not holding up anyone from starting new projects using current session bean technology. The customers who don't like the current Entity Bean model are generally already using Hibernate, TopLink, or one of the other POJO-based persistence solutions.

    If you want to split hairs, yes, the current injection model in EJB3 doesn't support some of the more exotic scenarios that Spring injection supports. That's why I said "basically the same functionality", not "the same functionality." Not all customers need all the DI features that Spring supports, and in the interest of keeping things simple the EJB 3.0 spec chose to support the features that cover the majority of use cases and to defer the other cases to a future rev, EJB 3.1, etc.

    The DI portion of Spring can play nicely with appservers, agreed. I'm not as certain about the feature that manages transactions, since that's the exclusive domain of the appserver/container according to the J2EE specs.

    And of course, IBM doesn't comment on future product plans and I'm certainly not going to start that on this forum!

    Randy
  136. I'm not as certain about the feature that manages transactions, since that's the exclusive domain of the appserver/container according to the J2EE specs.

    Scratch that...it occurred to me after hitting send that Spring could be getting the J2EE UserTransaction interface from the servlet's environment and starting/committing the tran with that.

    Something else also occurred to me though -- the question "Assuming you have a JavaEE5 appserver that supports EJB3 and JPA, what would be the scenarios where you'd want to add Spring into that? That's really what I was trying to get at in my original post. Rod mentioned that Spring supports DI scenarios that EJB3.0 doesn't; point taken.
  137. Randy
    I'm not as certain about the feature that manages transactions, since that's the exclusive domain of the appserver/container according to the J2EE specs.
    Scratch that...it occurred to me after hitting send that Spring could be getting the J2EE UserTransaction interface from the servlet's environment and starting/committing the tran with that.
    Yes, this is exactly what Spring does if you use Spring transaction management in a J2EE environment. It uses APIs that are in the J2EE specs, just as many folk have chosen to do themselves. (BMT is of course a legal choice even in EJBs, so this is supported.)

    Spring aims to provides a great programming model for transaction management; Spring defers XA etc. to an app server environment. So it doesn't aim to replace application server services, just provide an alternative way of driving them to EJB.

    This has some real benefits. For example, an important value add of Spring is that you can get the same programming model outside an app server as inside. No up-front choice between "local" and "global" transactions, with expensive rework required if, for example, you want to move from Tomcat to WebSphere. It's simply a matter of changing configuration. If you're in a Tomcat environment, for example, Spring itself can manage transactions using a single database, whether with say JDBC, Hibernate, TopLink or (soon) JPA transactions. But you can simply reconfigure to use Spring's JTA integration if you want to retarget to an app server using it's JTA functionality. No changes to Java code--indeed, only very localized changes to configuration.

    Thus Spring provides declarative transaction management in any environment, but is capable of using the transaction infrastructure available in a particular environment.

    Btw this is one of the things that BEA like about Spring: they can offer an upgrade path from Tomcat/Geronimo/WebLogic, without requiring customers to rewrite their applications.
    Something else also occurred to me though -- the question "Assuming you have a JavaEE5 appserver that supports EJB3 and JPA, what would be the scenarios where you'd want to add Spring into that? That's really what I was trying to get at in my original post. Rod mentioned that Spring supports DI scenarios that EJB3.0 doesn't; point taken.
    I think this does inevitably come down to a feature discussion, and I'm sure there'll be plenty of those in late 2006 or whenever we see a strong choice of EJB 3.0 implementations.

    Maybe ultimately our difference comes down mainly to the interpretation of the word "basically" :-)

    Rgds
    Rod
  138. If you want to split hairs, yes, the current injection model in EJB3 doesn't support some of the more exotic scenarios that Spring injection supports.
    Spring injection certainly supports a wide range of advanced scenarios. But in the middle lie many scenarios that are anything but exotic, and which EJB 3.0 injection misses, such as constructor injection, injection of objects that will not be placed in JNDI, injection of objects with a per-injectee instance lifecycle, sophisticated "autowiring", container extensibility features, and many more. These are important, and I don't regard this as "splitting hairs."

    It's worth remembering that it is no accident that Spring offers these capabilities: all these features beyond EJB3 injection were driven by the needs of large numbers of users since late 2002, when I first published 30,000 LOC and described an injection-based container with "J2EE Design and Development". Those needs aren't going to magically go away in an EJB3 environment. Which is why it's important that users are aware that EJB3 and Spring can play nicely together, and positioning EJB3 as a Spring replacement in the injection space is unrealistic.

    In the AOP/interception space, of course, the gap between what Spring offers now and what EJB 3.0 will offer is even greater. And in Spring 2.0 it will widen further--again because a significant number of Spring users want more, rather than fewer, features in this area.

    Point taken regarding "basically the same functionality": it was open to interpretation, and maybe I interpreted it differently from your intention.

    Rgds
    Rod
  139. Randy
    WebSphere users have no problem choosing to use current EJB technology.
    Frankly, this sounds rather out of touch--especially as our clients include
    - 2 global banks, which are among IBM's biggest clients
    - Probably the largest WebSphere account in Scandinavia

    All are trying to minimize or eliminate the use of EJB--and not merely entity beans. The productivity, testability and other problems associated with current EJB technology are widely known and companies large and small are adopting their strategies accordingly.
    In any case, the EJB2 session bean model is easily upward-compatible with the EJB3 model so that's certainly not holding up anyone from starting new projects using current session bean technology.
    An EJB3 implementation must be backward compatible. However, the new programming model is entirely different. The EJB 3.0 programming model has little in common with the present EJB programming model--and much more in common with the Spring programming model.

    In a nutshell: if you look at a Spring app and an EJB 3.0 app, you will see similarities (such as the use of DI). You can run EJB 2.x beans in an EJB 3.0 server, but you will ultimately want to rewrite the code, and it will look very different. The reality is that there is no obvious upward migration path to EJB 3.0--it's a new ball game.
    And of course, IBM doesn't comment on future product plans and I'm certainly not going to start that on this forum!
    If I was a WebSphere customer I would be very confused as a result of your posts. On the one hand you argue that EJB 3.0 is just great and means users (probably) don't need to use Spring. OTOH you are not giving a date for when they can actually use EJB 3.0, and I'd say it's pretty safe to guess that it's going to be (well) over one year. They'll need to migrate to Java 5, for a start.

    I was taking notes during Linda de Michiel's presentation at JavaPolis last week. (For those not aware of it, Linda is the EJB spec lead.) She applied the words "awkward" and "criminal" to the EJB 2.x programming model for session beans. I would suggest that your customers would do much better to adopt a POJO programming model today with Spring than endure 1-2 more years of an "awkward" and "criminal" programming model. And they'll be closer to the EJB 3.0 programming model if they ever want to go there.

    Rgds
    Rod
  140. Furthermore, even when IBM do ship EJB 3.0 support, companies will have to upgrade their whole WebSphere version to get it. That doesn't happen overnight. I've lost count of the folks who've come up to me (including last week at JavaPolis) to say how much they love the fact that Spring runs on whatever their current (old) container is. I had a guy last week (I think he was on a European government project) who told me that they'd just upgraded to...WebSphere 4.0.

    Rgds
    Rod
  141. I was taking notes during Linda de Michiel's presentation at JavaPolis last week. (For those not aware of it, Linda is the EJB spec lead.) She applied the words "awkward" and "criminal" to the EJB 2.x programming model for session beans. I would suggest that your customers would do much better to adopt a POJO programming model today with Spring than endure 1-2 more years of an "awkward" and "criminal" programming model. And they'll be closer to the EJB 3.0 programming model if they ever want to go there.RgdsRod

    If Linda chooses to apply the words "awkward" and "criminal" to a programming model spec that she led, that's certainly her prerogative. In fairness to her, I can certainly understand that a presentation to tout the benefits of EJB3 would use some hyperbole as part of the sales pitch.

    Randy
  142. Spring - EJB3[ Go to top ]

    Rod,

    <quote>
    It's surprising that this misconception has lingered for so long.
    </quote>

    I like the idea of Spring by implementing DI through the whole framework (except the XML configuration as many of developers already mentioned in this thread. But we have AndroMDA anyway, so we can generate those XML stuffs ;-)).

    The one point I really haven't understood sofar is that *Spring has absolutely no conflict with EJB3*. In my point of view it is different:

    - If you use Spring you surely can choose your environments to run your application: only web containers, a complete JEE containers, stand-alone... etc. with only changing the configuration files. This is very true and this is very practical. So Spring gives you the flexibility.

    - The 2.0 version of Spring will support MDB as well as you said, so I see Spring as a full-blown EJB3 alternative. We will be able to write an EJB3 application by only using Spring without EJB3 (the title of this thread should be changed into "Writing J2EE Application With or Without EJB" ;-)). You can write SLSB, (SFSB?), EB, MDB and TB (and all those remoting, etc.) just by using Spring alone. No need for EJB3. For writing business components EJB3 does *not* give you added value if you are using Spring. One additional advantage of Spring: you can use JDK 1.4 without annotations since EJB3 only supports JDK 1.5.

    - So, where is the case when I should use EJB3? Is it just because EJB3 at least a "de jure" standard (many vendors support it)? As far as I can see Spring has reached the "de facto" standard in this area, so I just cannot see the case with EJB3.

    - Another way around: if I'm using EJB3 why should I use Spring (for only the case of writing business components)? Using both is surely does not follow the rule of KISS. It will make your application a lot more complicated since you need to wrap your Spring app with EJB3 (example SSB, instead, you can simply use Spring remoting alone). So, if I'm using EJB3 I would not want to make my application more complicated by adding Spring just like what Randy has said. If you see this article Spring and EJB:
    http://www.javaworld.com/javaworld/jw-02-2005/jw-0214-springejb_p.html
     
    you will understand what I mean. It is just over complicated to add Spring and EJB together in one application and it won't give you added value as well aside from that beginners need to learn *both* things alltogether. AndroMDA generated these wrappers automatically but it is still too complicated.

    Again, I'm only concerning EJB3 component model and Spring => SLSB, SFSB, EB (this will use JPA), MDB, TB.

    This BEA article (from you ;-)) is IMO a very good comparison between an EJB and a Spring application and here you can already see that Spring *is* an alternative to EJB component model ;-):
    http://dev2dev.bea.com/lpt/a/448

    Just my 2 cents...

    Thanks,
    Lofi.
  143. Spring - EJB3[ Go to top ]

    Additional comments:

    IMO, it's OK to say "Yes, Spring is better alternative than EJB3, because ...". But such a comment can only come from you Rod, since you are the "father" of Spring...

    This makes at least a lot of things easier for the community:

    - Learning process view: instead of learning those new annotations (also XML deployment files) of EJB3 you can just learn the XML configuration files of Spring. You can have more time to learn AndroMDA with its Spring cartridge... ;-) Because we all know that "time" is always our constraint...

    - Management view: we can use Spring for *every* single part of the system implementation without having to touch EJB at all. So, Spring is a *real* alternative to EJB and *not half baked*. You can have those SLSB, SFSB, EB, MDB, TB with Spring. No need to mix both EJB3 and Spring so you can lean the learn process of all developers (very important to beginners too).

    I miss such a comment since what I've always heard from Spring developers is always: "Spring is *not* a competition to EJB3 or general EJB component model". This comment makes a decision to choose very hard. Again, from beginners point of view: you will save time and you don't want to learn both unnecessarily.

    Cheers,
    Lofi.
  144. Spring - EJB3[ Go to top ]

    Totally agree. The spring people seem a little too concerned about political correctness.

    EJB3 may have some merits (everything in the world has some merits). But why should EJB3 be *the only* politically correct? Just because of the half baked "standards" body JCP, or vendors who have millions to campaign for it?
  145. Spring - EJB3[ Go to top ]

    ...I see Spring as a full-blown EJB3 alternative. We will be able to write an EJB3 application by only using Spring without EJB3 (the title of this thread should be changed into "Writing J2EE Application With or Without EJB" ;-)). So, where is the case when I should use EJB3? Is it just because EJB3 at least a "de jure" standard (many vendors support it)? As far as I can see Spring has reached the "de facto" standard in this area, so I just cannot see the case with EJB3.- Another way around: if I'm using EJB3 why should I use Spring (for only the case of writing business components)? Using both is surely does not follow the rule of KISS. It is just over complicated to add Spring and EJB together in one application and it won't give you added value as well aside from that beginners need to learn *both* things alltogether. Again, I'm only concerning EJB3 component model and Spring => SLSB, SFSB, EB (this will use JPA), MDB, TB.This BEA article (from you ;-)) is IMO a very good comparison between an EJB and a Spring application and here you can already see that Spring *is* an alternative to EJB component model ;-):

    This is a good dialog. I too see Spring and EJB3, in effect, competing with each other. I don't agree with the positioning that it's some kind of front-end to a JavaEE EJB container. It is effectively an alternative/replacement for the session bean portion of an EJB container. Is this good or bad? I don't know... When I saw the question "Should Spring be added to the JavaEE 6 specs?" in the posting that started this thread, this is just what I was scratching my head over. Why would someone add an alternative EJB container to an environment that already has an EJB container in it? Prior to EJB3, I could more easly see why it would be worth doing that in order to get some important ease-of-use characteristics -- EJB 2.x session beans weren't POJOs, it was hard to test them outside of the container, the framework interfaces were invasive to your application interfaces, etc. So it was worthwhile for some to add Spring into the appserver environment in order to get around those issues.

    Now, both Spring and EJB3 let you take POJO objects containing business logic and hook them together, insert declarative transactional semantics, provide out-of-container testing. However, EJB3 will have many JavaEE vendors competing to provide the most easy-to-use, best performing, most scalable implementations. Every JavaEE app server will have it already present as part of the package.

    See, this dialog is interesting to me because we had very similar discussions on the EJB3/JPA expert group related to the benefits of standardizing the popular characteristics of Hibernate, TopLink, JDO and other POJO-based persistence tools. Historically, it's benefited the community at large to take the best programming model characteristics from various single-vendor solutions and meld them into a standard that multiple vendors can compete on based on quality of implementation. I realize some people on TSS may disagree, but believe it or not, that's even how EJB 1.1 and 2.x were developed. It is not just a bunch of eggheads sitting in a room saying "Wouldn't it be cool if we did things this way..." The EJB 1.x and 2.x models were patterned after models that various vendors' customers were successfully using to run their businesses. However, the fact is that the ways those customers write apps doesn't stand still -- new paradigms and models are developed as the state of the practice matures -- and the standards tend to incorporate those after they've been proven through use. EJB3 is no exception; it's no accident that POJO-based components, dependency injection and other popular patterns were incorporated there. Then customers can choose among multiple vendors that support the same programming model, competitive benchmarks get produced, and the community wins. That's why it was quite beneficial to have two of the point-solution persistence vendors (Oracle/TopLink, and JBoss/Hibernate) on the EJB3/JPA expert group.

    Randy
  146. Spring - EJB3[ Go to top ]

    I too see Spring and EJB3, in effect, competing with each other.

    Really? When will be WebSphere 7's GA? Should customers stop buying WebSphere 5/6 to wait for WebSphere 7?
    See, this dialog is interesting to me because we had very similar discussions on the EJB3/JPA expert group related to the benefits of standardizing the popular characteristics of Hibernate, TopLink, JDO and other POJO-based persistence tools.

    JDO is already a JCP standard or not?
    The EJB 1.x and 2.x models were patterned after models that various vendors' customers were successfully using to run their businesses.

    I heard at a WebSphere roadmap seminar in late 2004 that IBM contributed some 60% of the EJB spec. No wonder. EJB1.x and 2.x are probably simpler than the San Francisco framework.
  147. Spring - EJB3[ Go to top ]

    Randy
    This is a good dialog. I too see Spring and EJB3, in effect, competing with each other. I don't agree with the positioning that it's some kind of front-end to a JavaEE EJB container. It is effectively an alternative/replacement for the session bean portion of an EJB container.
    The real world isn't about black and white. I would not position Spring as a "front-end to a JavaEE EJB container," but characterizing Spring and EJB (any version) as mutually exclusive is just confusing to users. A significant number of users use EJB 2.x and Spring together today; I expect that many of the users who choose to try EJB 3.0 will rapidly hit the limits of what EJB 3.0 can do for them regarding Dependency Injection and AOP. (Once you embrace DI, for example, the limitations in the EJB 3.0 model seem quite puzzling.) Maybe such users should just switch entirely to Spring at that point; but I imagine that they will want to preserve as much of their investment as possible and using EJB 3.0 + Spring will be a good solution. Anyway, they may wish to use the many Spring services that EJB does not provide, and which do not overlap.

    More importantly, the comment that "Spring is effectively an alternative/replacement for the session bean portion of an EJB container" is quite wrong. Spring is actually much more than that. Yes, among other things, Spring provides a component model that features Dependency Injection and AOP, and also container services such as transaction management. But not only is that component model far more powerful, Spring also provides a wide range of other capabilities such as:

    - Many valuable class libraries, such as the JDBC abstraction, which can reduce LOC by about 60% compared to straight use of JDBC, and also eliminate many common errors, and valuable simplification for working with JNDI, JavaMail and other standard APIs
    - Integration with a huge range of technologies that EJB doesn't cover, within a consistent architectural approach
    - Support for fast, effective integration testing with no other container required
    - Seamless integration with AspectJ
    - Powerful web tier functionality, with Spring MVC and (soon) Spring Web Flow

    I've previously noted in this thread a number of areas where Spring goes beyond EJB 3.0 even in the area of overlap. These include:

    - Much more powerful DI features. Once users get a taste for DI they will rapidly hit a wall with EJB 3.0 DI. (As it was a book of mine, published in 2002, that brought DI to the mainstream in enterprise Java, and I was one of the people who coined the name, I think I'm entitled to an opinion on this subject.) At that point, they will probably need to recourse to either proprietary features (tying themselves to one platform vendor) or Spring, which will run on any platform.
    - True AOP functionality, if users choose, that goes way beyond EJB 3.0's very basic interception capability. The difference is important; with EJB 3.0 the recommended way of using AOP is to hardcode interceptor annotations around your business objects--including the FQN of the interceptor class. With a true pointcut model such as Spring AOP provides, you can truly modularize crosscutting concerns, and add a single piece of code that adds a desired behavior without modifying existing code. Works great with existing objects, and a better strategic path forward as well, meaning that maintenance is likely to be eased.
    - Integrated management capability. Spring can expose any managed object transparently for JMX management. EJB lacks any solution in this area.
    - Transparent remoting, including the ability to expose the same object simultaneously over different remote protocols. Note: EJB currently has some remoting capabilities that Spring lacks. In those cases, we presently recommend using EJB if people need those features. If there's sufficient demand we can fairly easily close those gaps.
    - Greater control. For example, EJB 3.0 does not offer choices regarding pooling strategy; with Spring you have total control over whether or not a bean is pooled. (Typically stateless objects should not be pooled.) Despite the sugar of the "simplified programming model," EJB continues to represent a "one size fits all solution" based around a monolithic container. IMO, this is looking increasingly dated.
    - Ability to extend the behaviour of the container without modifying container code. Spring provides numerous extension hooks.
    - Ability to run in a wide variety of environments, with the core functionality available on Java 1.3 and above.
    - Availability of the same programming model (DI and AOP) on the .NET platform. This is a consideration for a number of large enterprises.
    - Likely to provide better performance in most cases, due to the fact that features not required in a particular use case don't need to be activated. (I would encourage users to run their own benchmarks to verify this, as I don't expect any EJB vendors to be benchmarking Spring against their component model. See further comments below.)

    It's also worth noting that the preferred programming model for EJB 3.0 requires the use of annotations such as @Resource. (There is an XML alternative, but it's extremely verbose.) Spring, on the other hand, requires no annotations in business objects--meaning that Spring does not tie most business objects to the framework. So it's possible to get nearly the full value proposition of Spring even with existing objects: again, an important plus in a real world in which people should not need to rewrite their Java code every 2 years for the latest spec rev.
    When I saw the question "Should Spring be added to the JavaEE 6 specs?" in the posting that started this thread, this is just what I was scratching my head over.
    This is precisely why we in the Spring team are careful in how we position Spring. Making grand either/or claims is counterproductive. Anyway, we believe that allowing for innovation in the programming model space make sense, and don't think baking this into the platform is wise. IMO, there's a huge value in standardizing the underlying building blocks of J2EE, such as JTA, JNDI, JMS etc. But the attempt to standardize a component model--part of the programming model--with EJB, has thus far been a failure. Maybe this will change with EJB 3.0. But forgive me for being sceptical.
    Why would someone add an alternative EJB container to an environment that already has an EJB container in it?
    1. As I've noted, Spring is far more than an alternative to "the session bean portion of an EJB container," as you characterize it. So there are many compelling reasons that users might want to use Spring instead of or as well as the EJB 3.0 model.
    2. The assumption that the environment will "already have an EJB container in it" is highly questionable. For example, most Java web apps are better off running on Tomcat. What about deployment in an integration testing scenario? Customers benefit greatly from choice. For example, they can start on Tomcat and migrate to a high-end server if they need it, and still preserve the same programming model. Spring allows that, as I've pointed out previously in this thread. The traditional EJB-centric view of the world doesn't reflect reality. (If you want to mail me offline, I will happily give you the name of two global banks that are using Tomcat wherever possible. They were doing that before adopting Spring; now they just find that it's way more consistent and productive.)
    3. A Spring container is extremely lightweight. So there is negligible runtime overhead in adding a Spring container to any environment.

    Note that I'm just talking about session and message beans here. Spring will work very nicely with the Java Persistence API (EJB3 persistence). And note that JPA is not tied to the rest of EJB3--a welcome change in EJB 3.0.
    Historically, it's benefited the community at large to take the best programming model characteristics from various single-vendor solutions and meld them into a standard that multiple vendors can compete on based on quality of implementation.
    A little off topic, but let me quote from a Forrester report on the "Health of Open Source": Users interviewed by Forrester perceive Spring to be very high quality.
    EJB3 is no exception; it's no accident that POJO-based components, dependency injection and other popular patterns were incorporated there. Then customers can choose among multiple vendors that support the same programming model, competitive benchmarks get produced, and the community wins.
    Choice of ideas often trumps choice of implementations. So, for example, customers could choose several entity bean implementations, or they could choose, say, TopLink, for O/R mapping. However, TopLink actually worked, and could handle sophisticated domain models. (As could Kodo and Hibernate.)

    Further, the similarity in the application code written using those three true O/R mapping products was far greater than the similarity of code written to the old entity bean model than any other O/R mapping solution on the planet. (Because the entity bean model not only imposed baroque complexity, but entirely missed the key problems of O/R mapping, such as dealing with polymorphism.) Thus one of the goals of standardization--to ensure that customers' investment is preserved--was comprehensively missed by the old entity bean model, because it was such a poor model. Customers using TopLink, JDO or Hibernate are way better off with the coming move to JPA than customers using current entity bean technology.

    Btw, regarding "benchmarks being produced," we have done benchmarks of Spring vs commercial and open source EJB containers. The benchmarks favour the Spring component model--by a small but significant and repeatable margin vs the most performant commercial product; and by a huge margin against a popular open source application server. Obviously we can't name products (because of licensing restrictions from vendors), but some of the numbers are published in J2EE without EJB. I would love to be able to publish benchmarks comparing Spring and EJB 3.0 implementations for alternative implementations of the same functionality, and I hope that vendors will be supportive of the publication of such benchmarks.
    That's why it was quite beneficial to have two of the point-solution persistence vendors (Oracle/TopLink, and JBoss/Hibernate) on the EJB3/JPA expert group.
    You've forgotten SolarMetric/Kodo JDO. Patrick Linskey has made a significant contribution to the spec.

    Rgds
    Rod
  148. Spring - EJB3[ Go to top ]

    You've forgotten SolarMetric/Kodo JDO. Patrick Linskey has made a significant contribution to the spec.RgdsRod
    Rod

    Yes...I forgot to mention the additions from the JDO vendors, sorry. I was trying to make the point that JPA was more than stamping a standards label on Hibernate, which is something I hear constantly and which annoys others on the expert group (well, maybe not Gavin :)

    The other points you make, I guess we're going to have to agree to disagree.

    Randy
  149. Rod,

    thanks for the insight. So, in short if I'm going to build a *new* enterprise application and I need an enterprise component model I have 2 posibilities: ESPB (Enterprise Spring POJO Beans) or EJB. Using both makes no sense to me. And ESPB is more better than EJB (also EJB3) because the reasons you mentioned in your thread.

    So, my next question:
    Is there any migration HOW-TO from EJB to ESPB?

    - EB -> POJO + ...
    - SLSB -> POJO + ...
    - SFSB -> POJO + ...
    - MDB -> POJO + ...
    - TB (TimerBeans) -> POJO + ...

    Because the idea of EJB is actually good and we need those component types. Only the implementation with EJB 2.x is not good. Because the vacuum situation at the moment (EJB3 is not yet there and also those EJB3 containers) it would be the best way for Spring to offer this migration path... Any hints for such a HOW-TO migration?

    Cheers,
    Lofi.
  150. I've used Spring in several projects now, mainly for the IoC to make testing easier and Hibernate wrappers. It works great. However, the one thing that is just painful is debugging the stack trace when there's an error in one of the config files. Sure there's spring IDE but that a whole other thing to install and configure and figure out why springify my application didn't work. The format of the default messages are not very debug friendly. I've spent many times with colleagues trying to parse through huge blocs of text just to figure out that there was a typo in a package or class name.

    What's the best practice?
  151. I know the xml is fine in most cases, but in big projects it kind of sucks.


    If you feel no more xml on Spring, try Seasar2.
    (http://www.seasar.org/en/index.html)
    Seasar2 is a DI container with AOP which is based
    on the idea of "Less configuration"
    and "Convention over configuration".
    So, there are some good functions for
    less writing xml configs,
    such as auto register POJO to DI,
    annotations(enable for both J2SE1.4 and Tiger)


    Please see
     http://s2container.seasar.org/en/index.html

    And Seasar has more advantages, but you can find at
     http://www.seasar.org/en/products.html
  152. The sheer idiocy of such statements as these is truly appalling.

    I don't use spring on my web apps because I've already written a small handful of utility classes that do exactly what I need. These classes make things like JDBC simpler/more flexible (extensible queries), and things like HTML generation easier. They only took me a few days to write (if that). I can teach them to any decent Java developer in an hour. They do exactly what I want, exactly how I want it. I don't have to deal with the complexities of IOC, AOP, ORM, excessive XML configuration, etc.

    These frameworks (Spring, Hibernate, etc.) are HUGE and COMPLEX (large books written about either). Many of these frameworks are reflection based, or actually manipulate the bytecode at runtime which means that instead of being able to look at the code and know what is going on, you have to 'understand' what is going to happen when it runs. On top of that, many of these frameworks hold significant data in XML files (which are uncompiled).

    Less errors are caught at compile time, more at runtime. This is going the wrong direction. Didn't we just go through an excruciating process with Java 5 and generics to enable greater type safety and the ability to catch more problems at compile time?

    Now maybe some of this stuff is to get around the crappiness of EJB's and such. But using EJB's in the first place is stupid unless you have a distributed architecture (which many web apps don't have or need).

    I can only come to the conclusion that Java developers just LOVE to create complexity on top of other complexity to manage complexity that should not have been there in the first place. This is getting ridiculous.
  153. These frameworks (Spring, Hibernate, etc.) are HUGE and COMPLEX (large books written about either). Many of these frameworks are reflection based, or actually manipulate the bytecode at runtime which means that instead of being able to look at the code and know what is going on, you have to 'understand' what is going to happen when it runs.
    Why does manupulation of bytecode at runtime bother us so much ? Security ? Actually AOP raises the level of abstraction and makes the code simpler, the way you designed it. I have to agree that some frameworks are complex. So that means your code is simpler. What is the alternative ? ROR ;-) The debate shall start.
  154. These frameworks (Spring, Hibernate, etc.) are HUGE and COMPLEX (large books written about either). Many of these frameworks are reflection based, or actually manipulate the bytecode at runtime which means that instead of being able to look at the code and know what is going on, you have to 'understand' what is going to happen when it runs.
    Why does manupulation of bytecode at runtime bother us so much ? Security ? Actually AOP raises the level of abstraction and makes the code simpler, the way you designed it. I have to agree that some frameworks are complex. So that means your code is simpler. What is the alternative ? ROR ;-) The debate shall start.

    When the code says one thing, and the behavior is another, it is NOT simple or straightforward. These runtime 'enhanced' (hijacked) classes are evil. With this kind of voodoo going on at runtime, it's anyone's guess what is really happening.

    Frameworks like String/Hibernate raise the level of obfuscation immensely.

    The alternative is just to design/write good code from the beginning so that these frameworks are not needed.
  155. These frameworks (Spring, Hibernate, etc.) are HUGE and COMPLEX (large books written about either). Many of these frameworks are reflection based, or actually manipulate the bytecode at runtime which means that instead of being able to look at the code and know what is going on, you have to 'understand' what is going to happen when it runs.
    Why does manupulation of bytecode at runtime bother us so much ? Security ? Actually AOP raises the level of abstraction and makes the code simpler, the way you designed it. I have to agree that some frameworks are complex. So that means your code is simpler. What is the alternative ? ROR ;-) The debate shall start.
    When the code says one thing, and the behavior is another, it is NOT simple or straightforward. These runtime 'enhanced' (hijacked) classes are evil. With this kind of voodoo going on at runtime, it's anyone's guess what is really happening.Frameworks like String/Hibernate raise the level of obfuscation immensely.The alternative is just to design/write good code from the beginning so that these frameworks are not needed.
    While we're at it, why not go back to assembly and be free of all this compiler/garbage collector/virtual machine voodoo stuff too? ;)
  156. While we're at it, why not go back to assembly and be free of all this compiler/garbage collector/virtual machine voodoo stuff too? ;)
    I don't think you get the point.

    "When the code says one thing" means that when I see "a=1" I know the variable "a" is assigned with value "1". Who said I have to care what the assembly is?

    And when I see code "obj.f()", I'm expecting whatever the behavior defined in the function body of "f".


    Therefore, for a class Customer designed as:

    class Customer{
      public Customer(){}
      private Service1 service1;
      public Service1 getService1();
      public void setService1(Service1 service1){
        this.service1 = service1;
      }
    }


    I can reasonably write a test case as:

      Customer customer = new Customer();
      assertSame(null, customer.getService1());

    And expect it to work because that's the story the source code tells me.


    This is simply not a "must-true" situation when aspect weaving is in place. No more can a piece of code tell us exactly what it does. There may be hijackers somewhere!


    With that said, I'm not claiming that bytecode weaving is definitely evil.

    Take the dependency injection into domain objects as an example, there's just no pure object-oriented way that does the job both nicely and conveniently enough.

    Of course, I still think greater caution should be used when one's thinking about applying aspectJ.
  157. I don't think you get the point."When the code says one thing" means that when I see "a=1" I know the variable "a" is assigned with value "1". Who said I have to care what the assembly is?And when I see code "obj.f()", I'm expecting whatever the behavior defined in the function body of "f"...
    I beg to differ. If you overload the = operator on a C++ code for example, "a=1" just won't mean a simple assignment any more. Polymorphism just goes that way too in making your system do more than what's stated in the same place in the source code (I mean, the exact behaviour is defined elsewhere, similar to AOP's effect). GC goes in that direction too, as you just let you object go out of scope and it gets destroyed "magically", we don't have any of that actually in code, but somehow we know it happens and the effect it has in our apps.
    My point is, as languages evolve, this kind of "behind the courtains" behaviour is just going to increase, and all we can do is learn about them and be aware of its effects, as simply looking into code won't tell you the whole story anymore, as it is already happening in OO today.
  158. Hmm, Why my posts keep getting lost? Repost.

    My point is, as languages evolve, this kind of "behind the courtains" behaviour is just going to increase, and all we can do is learn about them and be aware of its effects, as simply looking into code won't tell you the whole story anymore, as it is already happening in OO today.
    You still don't get it. :-)

    The C++ operator overloading example doesn't back up your point either.

    With operator overloading, or encapsulation, or polymorphism, the semantics is defined and the story is clearly told (maybe at a higher level of abstraction though)

    A class tells me that "operator+()" is overloaded and the semantics: "blahblahblah".

    An interface hides implementation but does tell us what to expect, what might happen and what not to expect.

    Using your curtain metaphore, there might be lots of things going on behind a curtain, and most of the details we don't care; but I do get an idea about what is behind at a suitable abstraction level by reading the signs on the curtain.

    When a curtain reads "come in, food inside", I may not know if it is salad, pizza, steak or sushi, but I do expect to see "food".


    While with Aspect semantics, the curtain reads "food" but when I go in there may just be no food but a lion who's waiting for his food. :-)


    In short, with polymorphism, you can hide detail but you can't lie. With aop, you literally can do anything.
  159. In short, with polymorphism, you can hide detail but you can't lie. With aop, you literally can do anything.

    I accept that I'm more comfortable thinking about applications using AOP than most ;). I want to make two points in response to this - one is simply about the semantics of the AspectJ language, and one is a deeper point regarding the common "how do I understand what the code does?" issue.

    Firstly, it's not true that with *AspectJ* you can do "anything". In fact, the set of externally observable behaviours that advice can introduce at a join point (such as the execution of a "food()" method) are *no different* to the set of things you can do in an overridden method. AspectJ is very careful for example, to ensure that advice cannot throw a checked exception at a join point that is not in the signature of the member at the join point. Well-designed advice, like well-designed overriding methods, should only weaken pre-conditions, strengthen post-conditions, and ensure Liskov Substitutability is preserved.

    So to the second point.... "doesn't AOP make programs impossible to understand?":

    When you are trying to work with and understand a software system of any reasonable size, it's important to understand both the "big picture" of the design and how the various parts fit together, and also the local picture: "what happens at this point right here when the program runs?" The implementation of a crosscutting concern in an OO language makes the local flow of control explicit (you can see the call to the method right there for example). However, the big picture view - the design and intent of the concern in your system - is lost. I describe this phenomenon as "you can't see the design for the code" (cf. "you can't see the forest for the trees"). In an aspect-oriented implementation of the same crosscutting concern, the big picture view becomes obvious - you just need to look at the aspect. However, the local control flow is now implicit and so less obvious.

    So which view is more important: the big picture or the local view?? The truth is, "it depends" on what task you're trying to accomplish at the time. We need *both* views (Parnas has published some excellent papers in the past on the dangers of maintaining a system without understanding the big picture for example).

    So here's the thing. An AOP-aware IDE such as Eclipse with AJDT installed can recover the local control flow for you and present it directly in the IDE - making it explicit once more. It can do this because the behaviour is precisely defined as part of the semantics of the language. So you have both the big picture and the local view. But if you are using straight OO you have the local view, but recovering the big picture view for a crosscutting concern can be very difficult indeed (in fact, it's an area of active research in the academic community). Just think about how many times you do searches like "show me all the callers of 'x'" in your IDE as part of this kind of design reverse-engineering.

    I think comfort levels have a lot to do with this. Developers are so used to not having the big picture available, that they don't realize what's missing, whereas AOP and the accompanying tools feels new and uncomfortable. For me at least, once you're over the initial learning stage, the AOP-based solution offers clear and compelling advantages.
  160. Adrian, I'm not sure I get the point of " However, the big picture view - the design and intent of the concern in your system - is lost".

    Using OOP in certain senarios may not be as convenient, but I never feel like the big picture is lost.

    When I call "new TransactionProxy(new DomainObject())" --- Hopefully you agree this is OOP ---, I see clearly what's goning on. DomainObject doesn't handle transaction but TransactionProxy adds transaction support. Everything look like in good shape.


    I have basically two concerns about AOP currently:

    1. AOP locks me in. Once I rely on certain behavior to be weaved, (say, dependencies magically injected for "new DomainObject()"), I have no way to get naked again and do everything manual without dramatic code change. I can switch to a different aop impl, but no going back. It is like a replaceable but non-refundable shop.

    2. Aop doesn't seem to provide flexible programatic control. joinpoints and advices can only be statically and globally weaved. I can't go dynamic and localized to do nasty things like:

    void doDynamicLocalizedAop(Joinpoint joinpoint1, Advice advice1,
      Joinpoint joinpoint2, Advice advice2){
      if(condition1){
        doAop(joinpoint1, advice1,
          new Action(){
            public void run(){...}
          }
        );
      else if(condition2){
        doAop(joinpoint2, advice2,
          new Action(){
            public void run(){...}
          }
        );
      }
      else{
        //do not weave any advice.
        ...
      }
    }



    While OOP does great on these two.

    Rgds,

    Ben.
  161. uncomfortable. For me at least, once you're over the initial learning stage, the AOP-based solution offers clear and compelling advantages.

    No offense to some people, but you've hit the nail on the head. My impression of most of the Spring and AOP complaints is that most of them stem from people who've never used either as opposed to any real reasonable *real world* usage.

    I've only used the Spring AOP, but I think AOP is a real boon. I base this on not only my usage, but the code maintainability and how quickly those unfamiliar with the code ramp up.
  162. I've only used the Spring AOP, but I think AOP is a real boon.

    There are some issues with Spring AOP. The thing that I find awkward is that because of the way it is implemented (proxying), aspects don't always work when methods of the proxied class call each other. However, Spring's integration with Aspect/J can get around this.
  163. I've only used the Spring AOP, but I think AOP is a real boon.
    There are some issues with Spring AOP. The thing that I find awkward is that because of the way it is implemented (proxying), aspects don't always work when methods of the proxied class call each other. However, Spring's integration with Aspect/J can get around this.

    I look forward to exploring the more advanced features that this integration will bring. :-)
  164. I've only used the Spring AOP, but I think AOP is a real boon.
    There are some issues with Spring AOP. The thing that I find awkward is that because of the way it is implemented (proxying), aspects don't always work when methods of the proxied class call each other. However, Spring's integration with Aspect/J can get around this.
    I look forward to exploring the more advanced features that this integration will bring. :-)

    I would like to add that this sort of approach to integration is one of the reasons I think Spring is one of the best things to have happened to Java in recent years. There seems to be a wonderful lack of 'attitude' from Spring developers: "If you want to use Spring AOP, that works, but if you don't - hey! Use Aspect/J! We don't care - have fun!" You can use whatever persistence mechanism you like: JDBC, JDO, Hibernate, EJB, and others. You can use DI via Setter Injection or Constructor Injection, and you aren't told that one way is "right". You can use Spring MVC, but there is also integration support for JSF, Tapestry, WebWork and others.

    Such an easy-going and non-judgemental attitude seems to be rare these days.
  165. I've only used the Spring AOP, but I think AOP is a real boon.
    There are some issues with Spring AOP. The thing that I find awkward is that because of the way it is implemented (proxying), aspects don't always work when methods of the proxied class call each other. However, Spring's integration with Aspect/J can get around this.
    I look forward to exploring the more advanced features that this integration will bring. :-)
    I would like to add that this sort of approach to integration is one of the reasons I think Spring is one of the best things to have happened to Java in recent years. There seems to be a wonderful lack of 'attitude' from Spring developers: "If you want to use Spring AOP, that works, but if you don't - hey! Use Aspect/J! We don't care - have fun!" You can use whatever persistence mechanism you like: JDBC, JDO, Hibernate, EJB, and others. You can use DI via Setter Injection or Constructor Injection, and you aren't told that one way is "right". You can use Spring MVC, but there is also integration support for JSF, Tapestry, WebWork and others.Such an easy-going and non-judgemental attitude seems to be rare these days.

    Absolutely. Also, I've found Spring integration to be a good benchmark about other good products. For example, that's how I found about about ActiveMq.

    I've got some interesting ideas about introducing Asynchronous calls into our Struts/Spring/Hibernate framework via ActiveMq(or Lingo) and Spring AOP.

    This stuff is just awesome. We've got profiling, security, and caching support and you pretty much never(99%) have to tamper with the business logic.

    For me, Spring has revolutionized my development, helped us win business, attracted developers, and has put money directly into my pocket.

    Bring on v2!!
  166. These frameworks (Spring, Hibernate, etc.) are HUGE and COMPLEX (large books written about either). Many of these frameworks are reflection based, or actually manipulate the bytecode at runtime which means that instead of being able to look at the code and know what is going on, you have to 'understand' what is going to happen when it runs.
    Why does manupulation of bytecode at runtime bother us so much ? Security ? Actually AOP raises the level of abstraction and makes the code simpler, the way you designed it. I have to agree that some frameworks are complex. So that means your code is simpler. What is the alternative ? ROR ;-) The debate shall start.
    When the code says one thing, and the behavior is another, it is NOT simple or straightforward. These runtime 'enhanced' (hijacked) classes are evil. With this kind of voodoo going on at runtime, it's anyone's guess what is really happening.Frameworks like String/Hibernate raise the level of obfuscation immensely.The alternative is just to design/write good code from the beginning so that these frameworks are not needed.

    Not if you know what your are doing. OOP was thought to cause complexity. If you write bad code, you'll write bad OO and AOP code. If you can write good, code you'll enhance the app. With our framework, we can declaratively add security, caching, profiling, and transactions and the business logic stays pure. In 99% of the case, the business logic doesn't even need to be aware that those services are present.

    Ultimately, I hope that I'm competing for a project against every person NOT using these frameworks. It'll make my work more profitable in the long run!! :-)
  167. My role is to have to ramp into new projects with existing code bases every 6 to 18 months. And then either rewrite them as some greenfield thing, or do maintenance and expansion on them.

    I have during the last 6 years had to do weby things, ebj things, in-house framework things and finally we got spring in. In order of badness the frameworks have been:

    In-house bespoke (worst)
    EJB1
    Webby In-House
    EJB2
    JSP
    Struts
    Spring
      - no web stuff. Just IOC, off the sheld soap, Hibernate and home grown JMX

    So, I guess I believe Spring is the best thing yet to emerge, with struts still my prefered web infrastructure - but I don't do web anymore.

    Spring is far far better than learning some in-house thing (and yes I have written them in my time). The in-house frameworks tend to be where senior techies played for a year and then moved on, leaving their baby behind them.

    At least Spring has to take a beating from the community at large, and so stays on message, and does not (so far) just do things because they get the chance.

    BUT, I also agree that the scope of many projects does not need a framework, and some teams hate the very word.

    Jonathan
  168. The real question is : why to use Spring?
    I still wonder why; Ioc for testing purpose? There are other ways to automate testing, like Struts Test Case. Jdbc wrapper? There are other solutions like Hibernate or the Apache solution (sorry I don't remember its name).
    So I still wonder why I should use it, despite the fact that it is trendy and geeky...
  169. The real question is : why to use Spring?I still wonder why; Ioc for testing purpose? There are other ways to automate testing, like Struts Test Case. Jdbc wrapper? There are other solutions like Hibernate or the Apache solution (sorry I don't remember its name).So I still wonder why I should use it, despite the fact that it is trendy and geeky...
    Have you read something about Spring? Or you find it so geeky that is not worth your attention?JDBC Wrapper? How about Spring's support for hibernate, toplink,jdo,ibatis, and for that apache thingy you don't remember: OJB. It has it all. it eases development significantly. And imagine a project where you use 10 different frameworks, each performing it's own thing, each having at least one XML :D. Now that's nasty. I prefer putting all my eggs in one basket in this case, and go with a full spring solution. Just call me geek
  170. It's not just about testing and EJB. Those are just common use cases of Spring. For example, I had to developp a security authentification component last year. First we wanted to deploy it as a remote EJB to maintain just one component wich is accessible by every applications. An application was dependent of this module for applying it security. But the server where we wanted to deploy the EJB wasn't going to be ready in time. So we decided in the mean time to add a local copy of the component to the application so it didn't have to wait for the server to go in production. I had to add a small configuration and the code to support the use of a local component or a EJB component so we can switch easily when the server was going to be ready. I wish then I had used Spring, it would have taken me about 10 min to add this feature instead of 3 hours. Could have been a lot worst if my EJB weren't delegating services to POJOs. But what if a new requirement is to deploy the component as WebService??? Spring IoC just allows you to program without think about deployement considerations, choice of technology and that is really cool. You just have not to overuse it, use it for potential variations spots. Just my 2 cents.
  171. Flexibility during development?[ Go to top ]

    I've looked into Spring and I like the concepts. But, shame on me... I don't like "XML programming". Though I can clearly see the need for XML-based deployment descriptors when an application goes from development to production. What I like for my X-mas wishlist is to use annotations when in development and then use a tool to generate XML deployment descriptors that can be configured while in production.

    Regards Peter
  172. Oh come on people....let's face it! There are a lot of frameworks out there, it's up to you to choose one that best fits your project's needs. if you don't like spring fine, go try another solution, waste your own time writing in house frameworks, waste your own time trying to teach new developers in the company your framework, destroy your applications by putting those developers to code using the framework they just learned. It's your own choice.Spring is excellent for iterative development, allows tying application modules between them, and if you know what you're doin' , you'll find out that when your app's specs change from day to day, your code is far more flexible and easy to mantain. It's not about what tool you're using, but rather HOW you use it. And why should be using Spring like "XML PRogramming"? Show me one framework that doesn't have a single configuration xml.I use both struts and spring (all of spring including mvc, acegi, etc) and i find it more cumbersome and illogic to write the struts-config than writing the application-context. in spring mvc xml i tell the controller(simpleformcontroller, for example) where to go(formView and successView. I use this approach on MultiActionControllers as well, so i don't have to change the code, but rather the xml) and i tell him what command object CLASS to use. in struts, i have to configure both the command object and the action. If you know how to manage your spring xml's spring will seem a child's play. But please, be open minded. Don't be overconservative, don't reject something just because you don't fill the need for it. I find spring useful even for small projects, such as an online store or smth like that. I wouldn't use an application server for THAT kind of application and i DO need transactions.
    I also don't like combinations such as struts/spring/hibernate. i find them exotic. get a junior programmer work with 3 frameworks and ask him if he is not dizzy. THAT is XML Programming. Three different DTD's :D.
    If i am wrong, please correct me, but bring examples, please, don't talk out of personal belief.
  173. Hi Torvalds
    I also don't like combinations such as struts/spring/hibernate. i find them exotic. get a junior programmer work with 3 frameworks and ask him if he is not dizzy.
    indeed, it could be a bit too much at the beginning for a junior programmer, but then again, you wouldn't want some junior just to junior for a very long time. I think the fact that you can give the opportunity to people just off college gives them a big advantage in a couple of years.
    I'd like to give the people the motivation and encourage their initiative in learning very useful stuff that has been used elsewhere. At the end, you can only profit from that painful learning curve.
  174. I also don't like combinations such as struts/spring/hibernate. i find them exotic. get a junior programmer work with 3 frameworks and ask him if he is not dizzy. THAT is XML Programming. Three different DTD's :D.If i am wrong, please correct me, but bring examples, please, don't talk out of personal belief.

    This is where I think you are wrong. It is better for that Junior programming to use this stuff. The trick is to have an approach that works. At my company we use Struts,Spring, and Hibernate for junior developers with great success. You want a mess, have jr. developers write jdbc or scriptlet laced jsp pages with no borders in place. Or unleash them on some custom in-house framework with bad documentation and the main maintainer long since gone. If any one has question we've got books and forums for Struts, Spring, and Hibernate. In fact, I'll say that if your code is done correctly, the fact that you are using any of that stuff is almost completely transparent.
  175. I agree with you on the last part, it's what i said in my previous post. Good code is the best thing. But only you have the time to develop without any noisy manager telling you you are behind schedule. When dealing with large projects, i believe it's better to let some of the routine be handled by a framework. And spring is very useful when it comes to fast modifications. Couldn't agree more on the inhouse thingy. I've seen the freakiest "frameworks". Imagine picking up the Gof or the J2EE patterns book and start doing drag and drops in your projects(if that would be possible :)), add a sprinkle of stateless beans, a touch of entities, some dao's that don't implement any interface(i'd like to see how some modifications are done in that pile of garbage) and voila, you are so proud your developers look like jackasses when they look at the specs, you have the feeling you did something good :D. It's ok putting junior's to work with ONE framework (i mean struts, or spring, or hibernate, not all at once) and after some time letting them get a grip of the rest. start with struts for the web layer, and go down to the persistence layer.or the other way around. in this way, they'll get a good grip of all the layers and technologies, and they will have the guts to ask you:"why didn't we use spring in the first place?" :)
  176. I agree with you on the last part, it's what i said in my previous post. Good code is the best thing. But only you have the time to develop without any noisy manager telling you you are behind schedule. When dealing with large projects, i believe it's better to let some of the routine be handled by a framework. And spring is very useful when it comes to fast modifications. Couldn't agree more on the inhouse thingy. I've seen the freakiest "frameworks". Imagine picking up the Gof or the J2EE patterns book and start doing drag and drops in your projects(if that would be possible :)), add a sprinkle of stateless beans, a touch of entities, some dao's that don't implement any interface(i'd like to see how some modifications are done in that pile of garbage) and voila, you are so proud your developers look like jackasses when they look at the specs, you have the feeling you did something good :D. It's ok putting junior's to work with ONE framework (i mean struts, or spring, or hibernate, not all at once) and after some time letting them get a grip of the rest. start with struts for the web layer, and go down to the persistence layer.or the other way around. in this way, they'll get a good grip of all the layers and technologies, and they will have the guts to ask you:"why didn't we use spring in the first place?" :)

    See, I think you CAN have them learn all at once. We've done it with great success and near immediate productivity. Our developers were able to use Struts, Spring, and Hibernate because we already had a framework and approach in place that enabled them to ramp up quickly. When someone needs to add a new column to a domain object and that involves adding an Xdoclet tag, that's using Hibernate, but not necessarily understanding all of it. We had one guy enhancing the searching because he had real code examples of using Spring/Hibernate/Query by Example and Criteria. The framework APIs were almost irrelevent and he quickly got the job done.

    And if any questions come up, direct them to the right book. In fact, I believe that the worst thing is to put the jr. guys and just the front-end. The front-end gets a bad rap despite being the first thing the users see. I've got jr. people modifying front, middle, and data tier BECAUSE Struts/Spring/Hibernate make all three so approachable.