Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 34

Thread: Any negative experience?

  1. #11
    Join Date
    Nov 2004
    Location
    Hilversum - The Netherlands
    Posts
    1,054

    Default

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

  2. #12
    Join Date
    Aug 2004
    Location
    u.s.a
    Posts
    399

    Default

    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

  3. #13
    Join Date
    Nov 2004
    Location
    Hilversum - The Netherlands
    Posts
    1,054

    Default

    Quote 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

  4. #14
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    21

    Default

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

  5. #15
    Join Date
    Nov 2004
    Location
    Hilversum - The Netherlands
    Posts
    1,054

    Default

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

  6. #16
    Join Date
    Sep 2004
    Location
    Texas
    Posts
    155

    Default

    Quote Originally Posted by Ben Alex
    5. The domain model matters are not "swept under the carpet" at all.
    Then they are in a basement, inside a locked filing cabinet, in a disused lavatory with a sign saying "Beware of the leopard” on the door.

    I've read through the 640-page volume Professional Java Development With the Spring Framework, and found no serious discussion of the topic.

    Spring developers in these forums have suggested anemic domain solutions to these questions in the past, clearly prioritizing needs of the framework over design concerns. The only time I have seen a Spring developer give the matter serious concern in these forums is when http://forum.springframework.org/showthread.php?t=9846. That code sits outside of the packaged releases, and support requests have been deferred until release 1.4 of Spring.

    Quote Originally Posted by Ben Alex
    The reality is that domain objects need to have certain concessions made to permit their reuse in ORM tools and MVC forms.
    You may need to be more specific here. The challenges that I have encountered in implementing my domain objects are issues with Spring, not Hibernate.

    Quote Originally Posted by Ben Alex
    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.
    I am interested, can you point to where these classes are located? I am rummaging about in samples/quickstart... right now. This really gets back to my point about the lavatory and the leopard.

    There may be a terrific set of best practices out there for dealing with domain issues in Spring, but my point is that the Spring team has not been effective in publically articulating them if they do exist. I think from reviewing the forum activity it's kind of difficult to argue that point.

    Quote Originally Posted by Ben Alex
    We welcome constructive suggestions on how to improve Spring.
    I hope you are finding me constructive. I have a lot of respect for the project.
    Last edited by robyn; May 14th, 2006 at 08:42 PM.
    Corby

  7. #17
    Join Date
    Sep 2004
    Location
    Texas
    Posts
    155

    Default

    Quote Originally Posted by Ben Alex
    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?
    I might do that, but there seem to be some core philosophical differences, and until now I've been happier to 'agree to disagree' rather than get into a big debate over it when there are clearly some happy users.

    Quote Originally Posted by Ben Alex
    To assert that Spring quality is inconsistent should at the very least be justified by reference to specific concerns.
    Very well, as you wish.

    Spring MVC promotes itself as providing better separation between Model, View, and Controller, but it feels to me like tighter coupling. Spring MVC wants me to put view names into my controller. Spring MVC wants me to put form names into my .JSP files. These tight couplings don't exist in Struts, and it makes a lot of difference to me.

    When I search the Web forum for questions on chaining controllers (not discussed in Professional Java Development With the Spring Framework), Spring developers reply that 'for advanced navigation needs, you need to look at Spring Web Flow'. Huh?

    On page 504 of Professional Java Development With the Spring Framework, the developers tell us that "we explicitly decided not to include a tag library for generating markup" in .JSP files.

    So, instead of:

    Code:
    <html&#58;text property="name"/>
    we are given:

    Code:
    <spring&#58;bind path="command.name">
      <input type="text" name="$&#123;status.expression" value="$&#123;status.displayValue&#125;">
    </spring&#58;bind>
    Incredibly, we are given the rationale that it is easier for HTML developers to work with the second example than the first.

    Thankfully, it looks like a JSP 2.0 tag library is coming in Spring 1.3, representing an about face from their explicit design decision not to include such a library.

    In general, the decisions made in Spring MVC make less sense to me than those in Spring Core. But I recognize that this is a personal preference, and that smart people disagree with me.
    Corby

  8. #18
    Join Date
    Aug 2005
    Posts
    1

    Default

    Well, I'm a new Spring user, however as a new user perhaps I can bring a different perspective to the discussion. I'm also, going to try to be as constructive as I can here, so I hope the Spring developers don't get too upset with me . That disclaimer stated, here are some of aspects of Spring that have given me some pause:

    1. The current bean configuration file methods seem problematic for a few reasons:

    - Scalability – These files must turn into complete nightmares in projects which require large amounts of beans (i.e. controllers/validators/forms/DAOs etc.). There must be a more hierarchical and well defined approach to configuring these things (e.g. DAOs in once place, controllers in another etc). I realize you can arbitrarily segregate things on your own, however this “freedom” merely compounds the problem as everyone has their own way of doing something that the framework should (IMHO) define in the first place and more importantly enforce (in real life groups of programmers may not necessarily follow the arbitrary configuration file method).

    - Clarity – Looking at these XML files as a new user, I was assaulted by a lot of redundant information, obviously this has more to do with XML than Spring. However, I think XML has its place, but clearly this cannot be the best way to accomplish the “wiring” (injection) process that Spring is intended to do. I suspect a domain specific scripting language as already suggested would go along way to bringing more clarity to the “wiring” process.

    2. The so called “Anemic anti-pattern”
    - I’m going to have to second the opinions of the others in this thread, and say the “compromises” that must be made to a given domain model to utilize spring are somewhat concerning. A wise man one said in a well written book:

    “It's vital that we use J2EE to implement OO designs, rather than let our use of J2EE dictate object design.”

    The fellow was Rod Johnson, one of the founders of Spring. As I sit here now, I find myself thinking how I can design my OO domain so I can utilize Spring, instead of designing OO domain and simply utilizing Spring to wire it all together. The very fact that I (and presumably many others) have to think this way says that Spring clearly has too much influence over the OO design, and thus goes against the principle Rod once and may still believe in.

    Illustrative Example: Say you were designing a object to represent a virtual Horse, in a good OO design the Horse would have a “gallop” method, but in the Spring world you’d make a HorseGallopService and send your anemic "Horse" objects there to get them to gallop . Clearly an odd state of affairs.

    To those that dispute/refute this, it would be nice to see some Spring app examples similar to petclinic and jpetstore (though with a tad more business logic) which are implemented in as close to a true OO design as humanly possible. i.e. thin out the "service" layer as much as possible and put as much business logic back in the domain objects as possible.

    My solution for this? ....gosh I can't really think of any , though I think it is important to recognize any limitations, properly document them, and give developers means or "best practices" to minimize their impact.

    Anyhow, I'm going to continue plugging along and learning Spring. However I'm fighting with the notion of having to use a compromised OO design methodology in order to reap the benefits of Spring.


    Richard...

  9. #19
    Join Date
    Aug 2004
    Location
    Sydney
    Posts
    503

    Default

    I find the configuration files to quickly become big and unreadable.
    We found this to be an issue as well, but made it pretty much a non-issue by:

    1. Breaking config files into areas, e.g. single controllers.xml file that imports all other controller-*.xml files. We have >40 .xml files and it's now pretty easy to at least guess the correct file for some bean you're looking for.

    2. Use XmlBuddy in Eclipse, and use the outline view. This lets you quickly find a bean within an .xml file.

    Suggested improvements ...

    It would be cool if someone could create an Eclipse plugin that allowed hotkey'ing of a class, which then opened the corresponding Spring .xml file and selected that bean.

    e.g. Select MyClass at the top of the .java file, hit Ctrl-Alt-S (for Spring) or something, and then XmlBuddy editor opens showing the <bean ...> definition that references that class.

    I've built a few simple plugins but i've got absolutely no idea how to hook into the Java editor part of Spring.

  10. #20
    Join Date
    Aug 2004
    Location
    u.s.a
    Posts
    399

    Default

    Quote Originally Posted by gmatthews
    Suggested improvements ...

    It would be cool if someone could create an Eclipse plugin that allowed hotkey'ing of a class, which then opened the corresponding Spring .xml file and selected that bean.
    I don't think Spring IDE for Eclipse does that yet. But, perhaps the new Spring IDE with SpringXMLEditor does; I haven't tried the new stuff yet. That capability is essential.

Similar Threads

  1. Replies: 2
    Last Post: Oct 8th, 2007, 02:31 PM
  2. Replies: 0
    Last Post: Aug 4th, 2005, 05:26 PM
  3. Obfuscators experience with Spring
    By emarceta in forum Architecture
    Replies: 1
    Last Post: Mar 16th, 2005, 06:02 AM
  4. Real world application/project experience with Spring
    By morayani in forum Architecture
    Replies: 3
    Last Post: Feb 11th, 2005, 02:42 AM
  5. Replies: 0
    Last Post: Sep 16th, 2004, 01:45 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •