Any negative experience?

[ivom2gi]

I have delivered my first project(small sized though) with spring to a happy customer within the given time and budget. And for the very first time i am happy seeing the deveopment speed, lack of duplicate code, etc.

Before jumping into the next, ten times bigger project I would like to know about IRL limitations faced by developers using spring. I have read different books, manuals and APIs so I should be aware of all the theoretical aspects, but still ... it cannot be as good as it seems ...

[Colin Yates]

irl?

[cepage]

Before jumping into the next, ten times bigger project I would like to know about IRL limitations faced by developers using spring. I have read different books, manuals and APIs so I should be aware of all the theoretical aspects, but still ... it cannot be as good as it seems ...

I'm very happy with Spring, but there are two big problems I run into.

First, Spring does not have a consistent philosophy for dealing with stateful objects, domain objects in particular. The main Spring guys tend to promote the Anemic Domain Model antipattern as a solution to this, which is just sweeping the problem under the rug.

You can get a sense from this http://forum.springframework.org/showthread.php?t=15294 as to how much confusion there exists on how to properly manage rich domain objects within a Spring application. I have not yet encountered any unsolvable problems in this area, but there tends to be a lot of wailing and gnashing of teeth in the absence of best practices.

Second, once you get outside the outstanding Spring Core packages, the quality of the Spring brand tends to dilute real fast. Some people really like Spring MVC, but I have found it to be a mess. Other subprojects like Spring Modules and Spring Rich Client undergo changes in management every quarter or so, and get further and further from a 1.0 release with each passing month.

In the end, however, I would recommend the use of Spring even in larger projects.

[Alarmnummer]

Before jumping into the next, ten times bigger project I would like to know about IRL limitations faced by developers using spring. I have read different books, manuals and APIs so I should be aware of all the theoretical aspects, but still ... it cannot be as good as it seems ...

I'm very happy with Spring, but there are two big problems I run into.

First, Spring does not have a consistent philosophy for dealing with stateful objects, domain objects in particular. The main Spring guys tend to promote the Anemic Domain Model antipattern as a solution to this, which is just sweeping the problem under the rug.

*nods*

Second, once you get outside the outstanding Spring Core packages, the quality of the Spring brand tends to dilute real fast. Some people really like Spring MVC, but I have found it to be a mess. Other subprojects like Spring Modules and Spring Rich Client undergo changes in management every quarter or so, and get further and further from a 1.0 release with each passing month.

I even find code from Spring core packages difficult to understand. I keep jumping from class to class without having a feeling of true understanding. If you just use Spring, you won`t see it. But if you get to the internals.. I`m not getting excited and I`m happy when I can close the sources.

In the end, however, I would recommend the use of Spring even in larger projects.

*nods again* btw: I only have experience with Spring in small and medium sizes projects..

[Colin Yates]

I have used spring on 6 medium to large web projects, including webflow on the current project.

I have to say that Spring is an excellent base. For sure, there are faults with it and some missing pieces, but stick to the released versions and you won't go wrong.

You have to remember that spring core (IMO) is about two things; the *concept* of dependency injection, and an *implementation* of a dependency injection framework.

Even if I wasn't using spring, I would still be using the guiding principles that spring uses, i.e. POJOs (for unit testing) + collaborators, developing to interfaces (allows mocking of collaborators), seperation of business logic/configuration etc.

When you get really really familiar with something, it is easy to find faults with it and difficult to remember how much easier other things are. It is a testimony to springs excellence that people forget how difficult things would be without it Not sure I explained that right

Go with spring until it proves too restrictive. I've never reached that point yet

[dcengija]

I find the configuration files to quickly become big and unreadable. Surely, imports and smart partitioning into smaller, domain-oriented files help, but still, that's the area which needs more work. Support for scripting languages, maybe?

Regards,
Davor

[hucmuc]

I find the configuration files to quickly become big and unreadable. Surely, imports and smart partitioning into smaller, domain-oriented files help, but still, that's the area which needs more work. Support for scripting languages, maybe?

Regards,
Davor

I agree. The configuration files are actually nice to wire things together and the philisophy behind them sounds great. I keep reading/hearing that the configuration files are a plus in Spring. But as you pointed out, when the project gets large it becomes a bit of a nightmare. This is especially true when new developers come on board and see a mass of configuration files and when they forget to correctly IoC one bean the whole app blows up. This is why unit AND integration testing is really required in which the production configuration files must be used somewhere in regression tests.

Dino

[hucmuc]

Before jumping into the next, ten times bigger project I would like to know about IRL limitations faced by developers using spring. I have read different books, manuals and APIs so I should be aware of all the theoretical aspects, but still ... it cannot be as good as it seems ...

I'm very happy with Spring, but there are two big problems I run into.

First, Spring does not have a consistent philosophy for dealing with stateful objects, domain objects in particular. The main Spring guys tend to promote the Anemic Domain Model antipattern as a solution to this, which is just sweeping the problem under the rug.

You can get a sense from this http://forum.springframework.org/showthread.php?t=15294 as to how much confusion there exists on how to properly manage rich domain objects within a Spring application. I have not yet encountered any unsolvable problems in this area, but there tends to be a lot of wailing and gnashing of teeth in the absence of best practices.

I too have not been satisfied with how the Spring developers try to explain the philosophy on stateful objects. If you look at the spring code it is conveniently swept under the rug. For example, the BeanWrapper class. The spring source code always instantiates with a BeanWrapperImpl class. Why isn't this injected? I wish it were since I could implement my own version and could write an ant task to validate configuration files.

Since I've been using Spring, I sometimes change the way I implement things. Instead of using stateful objects, I would use singletons and pass in variables as arguments. Why? It is much easier to inject singleton based objects than prototypes.

There's something missing here and I can't find a consistent and explainable solution.

Dino

[Alarmnummer]

I find the configuration files to quickly become big and unreadable. Surely, imports and smart partitioning into smaller, domain-oriented files help, but still, that's the area which needs more work. Support for scripting languages, maybe?

Regards,
Davor

T think part of the problem is the XML syntax (it is extremely verbose). I too have configuration files that are getting quite big, and with the last few projects I have as many as 7/8 configuration files.

I hope in the future the xml syntax will be dropped and a domain language will be introduced. Because spring doesn`t allow the syntax of xml to be modified, it should be easy to write a domain language. Java has excelent parser generators (SableCC for example) so creating a language is not very complicated.

[Ben Alex]

Just a few quick points:

1. Spring's IoC container is not tied to XML. There are various bean definition readers, such as the properties reader. XML is the most popular, but Spring != XML.

2. There have been recent improvements in the XML syntax. It's now less verbose. Awareness of current features like <property name="foo" ref="fooService"/> and inner beans significantly reduce XML.

3. The quality of the Spring Core package is very high. The MVC framework is also very high. If you have specific concerns with the MVC approach, why not raise them in the MVC forum so the rationale can be explained? As far as the rest of Spring goes, I've personally used nearly every feature in large, real-world projects (Hibernate, JMS, JMX, JDBC, MVC, security, timers, AOP, remoting, TX etc) and can say nothing other than Spring is consistently of extremely high quality. The technical consistency and technical robustness that Juergen (as "the gatekeeper") applies to all parts of the Spring Core is to be highly commended. To assert that Spring quality is inconsistent should at the very least be justified by reference to specific concerns.

4. Projects like Spring Rich and Spring Modules, to be fair, are not marketed as being ready for production projects. Their version numbers - or even absence of a release - shows their early stage. It's good the developers are working on such projects and providing a base upon which to develop more comprehensive solutions. Everything has to start somewhere. If you can do a better job, by all means help them out and contribute code (or simply don't use these early-stage modules).

5. The domain model matters are not "swept under the carpet" at all. In the Spring Training courses we advocate first focusing on your domain objects and their relationship with service layer interfaces, only dealing with implementation issues like Spring and concrete implementations after those preliminary steps have been completed. The reality is that domain objects need to have certain concessions made to permit their reuse in ORM tools and MVC forms. If you want to see production-quality services and domain layers that reuse these concerns, check out the Acegi Security Domain subproject (in CVS). It is a simple few classes that show you how to do it properly. It's not part of core Spring or even core Acegi Security because developers will typically introduce similar classes and interfaces within their own application if appropriate. Feel free to cut 'n' copy it into your codebase and customise further.

6. Developers forgetting to configure beans properly is part of life. That's why you should use InitializingBean to check that the bean is properly wired. If you don't like a dependency on Spring, use an init-method. Also consider the alternative of no Spring. What then? Project-specific Service Locators, singletons and factories - which have an obviously greater learning curve and are "needless infrastructure code" that application developers ideally should not be writing.

7. Configuration files need to be managed as separate entities. The <import> tag will help you manage this.

To return to the original thread, Spring is successfully used in very large applications. See http://interface21.com/users.html for some examples.

We welcome constructive suggestions on how to improve Spring.