Announcement Announcement Module
Collapse
No announcement yet.
Any negative experience? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Any negative experience?

    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 ...

  • #2
    irl?

    Comment


    • #3
      Re: Any negative experience?

      Originally posted by ivom2gi
      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.
      Last edited by robyn; May 14th, 2006, 08:59 PM.

      Comment


      • #4
        Re: Any negative experience?

        Originally posted by cepage
        Originally posted by ivom2gi
        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..

        Comment


        • #5
          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

          Comment


          • #6
            Re: Any negative experience?

            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

            Comment


            • #7
              Re: Any negative experience?

              Originally posted by 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
              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

              Comment


              • #8
                Re: Any negative experience?

                Originally posted by cepage
                Originally posted by ivom2gi
                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
                Last edited by robyn; May 14th, 2006, 08:58 PM.

                Comment


                • #9
                  Re: Any negative experience?

                  Originally posted by 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
                  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.

                  Comment


                  • #10
                    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.

                    Comment


                    • #11
                      Originally posted by 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.
                      The point is that at the moment there are no serious alternatives. I heard something about groovy integration in the beginning, but that has been some time.

                      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.
                      Yes.. but that doesn`t make XML less verbose. If I write config files, I have the option:
                      -create larger beans (with a lot of inner beans) so they don`t polute config files and only have a meaning in a specific bean
                      -create a lot of smaller beans.. but now the configuration file(s) gets polluted with beans that are only used in a specifc context (they are outside of their scope).

                      If I remove the XML syntax and introduce a domain language, I can guarantee that the config files will be a lot shorter.

                      [edit]
                      Here is an example of the original spring configuration.

                      Code:
                      <bean id="indexUpdaterScheduler"
                      		  class="org.jph.spring.scheduling.concurrent.ScheduledThreadPoolExecutorFactoryBean">
                      
                      		<property name="threadFactory">
                      			<bean class="org.jph.concurrent.StdThreadFactory">
                      				<constructor-arg index="0" value="2"/>
                      				<constructor-arg index="1" value="indexUpdater"/>
                      			</bean>
                      		</property>
                      
                      		<property name="scheduledWithFixedDelayRunnables">
                      			<list>
                      				<bean class="org.jph.spring.scheduling.concurrent.ScheduledWithFixedDelayRunnable">
                      					<property name="runnable">
                      						<bean class="org.jph.spring.scheduling.MethodInvokeSequenceRunnable">
                      							<property name="methodInvokerList">
                      								<list>
                      									<bean class="org.springframework.util.MethodInvoker">
                      										<property name="targetObject" ref="indexUpdater-image"/>
                      										<property name="targetMethod" value="process"/>
                      									</bean>
                      
                      									<bean class="org.springframework.util.MethodInvoker">
                      										<property name="targetObject" ref="indexReaderProviderService-image"/>
                      										<property name="targetMethod" value="refresh"/>
                      									</bean>
                      
                      									<bean class="org.springframework.util.MethodInvoker">
                      										<property name="targetObject" ref="indexUpdater-movie"/>
                      										<property name="targetMethod" value="process"/>
                      									</bean>
                      
                      									<bean class="org.springframework.util.MethodInvoker">
                      										<property name="targetObject" ref="indexReaderProviderService-movie"/>
                      										<property name="targetMethod" value="refresh"/>
                      									</bean>
                      								</list>
                      							</property>
                      						</bean>
                      					</property>
                      					<property name="initialDelay" value="5"/>
                      					<property name="delay" value="30"/>
                      					<property name="timeUnit" ref="java.util.concurrent.TimeUnit.SECONDS"/>
                      				</bean>
                      
                      				<bean class="org.jph.spring.scheduling.concurrent.ScheduledWithFixedDelayRunnable">
                      					<property name="runnable">
                      						<bean class="org.jph.spring.scheduling.MethodInvokeSequenceRunnable">
                      							<property name="methodInvokerList">
                      								<list>
                      									<bean class="org.springframework.util.MethodInvoker">
                      										<property name="targetObject" ref="indexOptimizer-image"/>
                      										<property name="targetMethod" value="optimize"/>
                      									</bean>
                      
                      									<bean class="org.springframework.util.MethodInvoker">
                      										<property name="targetObject" ref="indexReaderProviderService-image"/>
                      										<property name="targetMethod" value="refresh"/>
                      									</bean>
                      
                      									<bean class="org.springframework.util.MethodInvoker">
                      										<property name="targetObject" ref="indexOptimizer-movie"/>
                      										<property name="targetMethod" value="optimize"/>
                      									</bean>
                      
                      									<bean class="org.springframework.util.MethodInvoker">
                      										<property name="targetObject" ref="indexReaderProviderService-movie"/>
                      										<property name="targetMethod" value="refresh"/>
                      									</bean>
                      								</list>
                      							</property>
                      						</bean>
                      					</property>
                      					<property name="initialDelay" value="14400"/>
                      					<property name="delay" value="86400"/>
                      					<property name="timeUnit" ref="java.util.concurrent.TimeUnit.SECONDS"/>
                      				</bean>
                      			</list>
                      		</property>
                      	</bean>
                      here is the same bean written in a domain language
                      Code:
                      import org.jph.spring.scheduling.concurrent.*;
                      import org.jph.concurrent.*;
                      import java.util.concurrent.TimeUnit.*;
                      
                      bean id&#40;indexUpdaterScheduler&#41; class=ScheduledThreadPoolExecutorFactoryBean&#123;
                      	
                      	threadFactory bean class=StdThreadFactory&#40;value&#40;2&#41;,value&#40;indexUpdater&#41;&#41;;
                      
                      	scheduledWithFixedDelayRunnables list&#91;
                      		//index-updaters scheduling
                      		bean class= ScheduledWithFixedDelayRunnable&#123;
                      			
                      			runnable = bean class=MethodInvokeSequenceRunnable&#123;
                      				
                      				bean class=MethodInvoker &#123; 
                      					targetObject ref&#40;ndexUpdater-image&#41; 
                      					method value&#40;process&#41;&#125;		
                      				bean class=MethodInvoker &#123; 
                      					targetObject ref&#40;indexReaderProviderService-image&#41; 
                      					method value&#40;refresh&#41;&#125;		
                      				bean class=MethodInvoker &#123; 
                      					targetObject ref&#40;indexUpdater-movie&#41; 
                      					method value&#40;process&#41;&#125;		
                      				bean class=MethodInvoker &#123; 
                      					targetObject ref&#40;indexReaderProviderService-movie&#41; 
                      					method = value&#40;refresh&#41;&#125;		
                      			&#125;
                      	
                      			initialDelay value&#40;10&#41;			
                      			delay value&#40;30&#41;
                      			timeUnit ref&#40;TimeUnit.SECONDS&#41;
                      		&#125;
                      
                      		//optimize scheduling
                      		bean class= ScheduledWithFixedDelayRunnable&#123;
                      			
                      			runnable  bean class=MethodInvokeSequenceRunnable&#123;
                      				bean class=MethodInvoker &#123; 
                      					targetObject ref&#40;indexOptimizer-image&#41; 
                      					method value&#40;optimize&#41;&#125;
                      				bean class=MethodInvoker &#123; 
                      					targetObject ref&#40;indexReaderProviderService-image&#41; 
                      					method value&#40;refresh&#41;&#125;
                      				bean class=MethodInvoker &#123; 
                      					targetObject ref&#40;indexOptimizer-movie&#41; 
                      					method value&#40;optimize&#41;&#125;
                      				bean class=MethodInvoker &#123; 
                      					targetObject ref&#40;indexReaderProviderService-movie&#41; 
                      					method value&#40;refresh&#41;&#125;
                      			&#125;
                      
                      			initialDelay value&#40;14400&#41;			
                      			delay value&#40;86400&#41;
                      			timeUnit ref&#40;TimeUnit.SECONDS&#41;
                      		&#125;
                      	&#93;
                      &#125;
                      The syntax can be improved. Instead of using bean class='Foo' it would be more natural to say: new Foo. But this is only an attempt to create a better and clearer syntax.

                      Comment


                      • #12
                        Hmmm. If so, why not just go ahead and write it in straight Java or a Scripting language, why a domain specific language? Even a great domain specific language (like your example) will require a learning curve and discourage many from using it.

                        I get a little subtle spider sense tingle though. I remember the early EJB stuff was like that. You had to write the configuration (descriptor) in Java, compile, and yada yada yada. So changing a string meant that whole cycle again.

                        Edit:
                        One of the issues is the problems inherent in XML itself. But, there are many approaches to mark up, see for example:
                        http://www.pault.com/pault/pxml/xmlalternatives.html

                        J. Betancourt

                        Comment


                        • #13
                          Originally posted by jbetancourt
                          Hmmm. If so, why not just go ahead and write it in straight Java or a Scripting language, why a domain specific language?
                          Because Java is not usable for Spring as a configuration language. My suggestion is that the AST (abstract syntax tree) for the XML and the domain specific language (lets call it the Spring language) are exactly the same. So after they are parsed there is no difference between a file parsed with XML and the Spring-language version. Only the parsers are different, after the AST has been build.. they all can share the current mechanisms to configure the internals of the application context.

                          Even a great domain specific language (like your example) will require a learning curve and discourage many from using it.
                          Yes.. but you will have the same learning curve for the XML variant. A domain language and the current xml syntax have the same semantics, only a different syntax.

                          If you look at my example you will see that the structure is identical.. only a lot less verbose.

                          I get a little subtle spider sense tingle though. I remember the early EJB stuff was like that. You had to write the configuration (descriptor) in Java, compile, and yada yada yada. So changing a string meant that whole cycle again.
                          You don`t understand it. There is no difference between an XML file containing the configuration, or another textfile (written in the Spring language) containing the configuration.

                          Edit:
                          One of the issues is the problems inherent in XML itself. But, there are many approaches to mark up, see for example:
                          http://www.pault.com/pault/pxml/xmlalternatives.html

                          J. Betancourt
                          I think XML is a bad choice in most cases (Spring also). XML is to verbose.. it is perfect for data exchange and data transformation. It is bad for configuration (done by humans) and programming.

                          Terence Parr has a nice article about it.
                          Humans should not have to grok XML

                          Comment


                          • #14
                            I think XML is a bad choice in most cases (Spring also). XML is to verbose.. it is perfect for data exchange and data transformation. It is bad for configuration (done by humans) and programming.
                            That's why we need a fully fledged config GUI with trees, lists, contextual menues, auto-completition, flowers, butterflies etc... :-)

                            Comment


                            • #15
                              Originally posted by dcengija
                              I think XML is a bad choice in most cases (Spring also). XML is to verbose.. it is perfect for data exchange and data transformation. It is bad for configuration (done by humans) and programming.
                              That's why we need a fully fledged config GUI with trees, lists, contextual menues, auto-completition, flowers, butterflies etc... :-)
                              I never felt happy with that. I would rather have a file I can edit.

                              The root of a lot of evil is the fact that XML isn`t applied in the right situations. Before XML people created there own syntax, but since XML everybody is building AST`s directly from XML. I think this is not a step foreward.. but a big step backward..

                              Comment

                              Working...
                              X