|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 89
Messages: 89
Messages: 89
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Arif Rachim: Five Reasons I think I won't use Spring
Arif Rachim has posted "5 Reasons why I think I will not use Spring," detailing some issues he has with Spring: bloated configuration, XML configuration, lack of strong type checking, performance of the container, and the Spring binding process (i.e., applications that use Spring *must* use Spring...)
Most of the issues he details are with reference to the configuration of Spring. For example (with edits for grammar):1. Spring configuration is bloated.
My team develops enterprise application using a Dependency Injection framework. There are more than 1500 classes in that project, and separated to more than eleven modules. To my experience in a real world, "we made service objects less than the objects that depend on that service." If we use Spring, when we made 1000 actions that depend in 100 service, it means we have to make configuration on 1000 beans that depend on 100 services. The configuration gets worse if the actions continue growing in numbers - we must be even more careful when we want to refactor something, as we dont want to break existing code.
You might start thinking using autowire by type - no, that would be a bad idea. Then why not use autowire by name? That sounds silly. What if we have different names in configuration for different object? Well, I guess that's going to be another long nite at the office. His fifth concern is probably the most relevant:Spring is a container that just promises to help us build loosely coupled technology, Spring does not really concern that much about tightly coupled. I'm very sure that once we use spring lib other than spring-core.jar that means our application cannot live without Spring. There's no "standard" way to get elements from Spring without depending on Spring, nor is there a clear path to having transparent use of such a library. (That said, Struts 2 is able to use Spring to locate actions through a very simple configuration. If Struts 2 can do it...)
What do you think?
|
|
|
Message #235680
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
There is room for improvement, but Spring still rocks
I agree that the Spring configuration is verbose. With the introduction of domain specific syntax in Spring 2 it has become a little better, but there is still room for improvement.
Getting rid of the XML would be a good step forward and that is why I'm currently playing with the DSL for Spring that Grails provides. Although the documentation is very limited, I see many advantages (less typing, groovy language features combined with the dsl.. so you are not forced to create beanfactories for simple stuff like adding listeners to a bean). But the quality of this part of grails really needs to improve to make it usable for mainstream developers.
And for the Spring dependency: Spring is much more than just an IOC container. It provides integration for a lot of api's. As soon as you are going to replace Spring by something else, this integration has to be replaced also. If you are going to use a very very lightweight IOC container, you will have to set up this integration functionality yourself. It also means that your code still depends on some integration code.
I would like to see where dynamic language like (J)Ruby and Groovy can take Spring. Spring for the integration logic, and a powerful and extendable DSL for bean creation.
|
|
|
Message #235681
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not really true anymore
You can get a class automatically registered as a Spring bean using @Component -annotation, and then inject dependencies to it with @Autowired and @Resource -annotations.
A suggested solution would be to configure the '100 services' in the traditional XML way (this provides ultimate flexibility and a 'directory' of services), and use annotation based configuration for the '1000 actions'.
There is also a possibility of using 'Spring JavaConfig', where as the name suggests the configuration is done in Java instead of XML.
However, i generally do agree with the post -- Springs dependency injection could be more elegant -- but in the end the choice once again is not about elegance, it's about business realities, and this is where Spring is really strong.
Regards,
Henri Karapuu
|
|
|
Message #235683
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
completeley disagree.
Spring is not invasive, its model is elegant and powerful.
IoC is an important Pattern, must be understood clearly: Spring implements it in an elegant way.
I think Spring configuration is not bloated, but if you like the @Annotation, take a look at SpringConfig.
If you think Spring is bad, what about EJB3/2 ?
For the last reason...I think it is completely wrong!
For sure, if you use the SpringFramework, you must depend on spring-core.jar, that's so easy!
Cannot your application live without spring?
I think million of j2ee applications cannot!
Otherwise, j2ee applications can live without EJB !
|
|
|
Message #235686
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How hard is creating objects anyway?
I've never understood why creating objects is so burdensome that a complete other framework with a O(n) configuration burden is required. Just create the darn objects.
|
|
|
Message #235687
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How hard is creating objects anyway?
I've never understood why creating objects is so burdensome that a complete other framework with a O(n) configuration burden is required. Just create the darn objects.
Another little boy shouting "the emperor has no clothes". You better watch out.
|
|
|
Message #235690
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How hard is creating objects anyway?
I've never understood why creating objects is so burdensome that a complete other framework with a O(n) configuration burden is required. Just create the darn objects.
Don't worry, you will understand it very clearly when you start unit testing your first large project.
|
|
|
Message #235692
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
Come on. This must be the worst post so far this year.
You can use xml, annotations, java, or construct some other configuration option using the spring api. Nothing is bloated, painful or not strongly typed if you don't want it too. But you have to know what you are doing, and why, no matter whats the name of he framework or language.
If startup time is 5 or 30s for an application that I start once a year or month is really of no interest.
I’m very sure that once we use spring lib other than spring-core.jar that means our application cannot live without spring.
Guess what! Once you use foo.jar, your application can't live without foo.jar either...
The problem is that people are using frameworks that solve complex things in a user friendly way, without having a clue about whats going on under the surface... and then blame the framework when their bad design breaks. Same thing goes with Seam or any other framework. Even though it's really easy and fast to write Hello world, you have to know whats going on, what the framework is doing so you don't have to.
/Magnus
|
|
|
Message #235693
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How hard is creating objects anyway?
That's right. If you need objects from jndi, just copy and paste the code that makes the lookup into every class. I mean, how hard is that? Or write a 3000 lines service locator and call it from everywhere. It's reeally simple to do.
|
|
|
Message #235699
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Vindication!
Finally! Vindication! One person in the Java community finally agrees with me that Spring sucks.
;-)
|
|
|
Message #235701
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How hard is creating objects anyway?
> Don't worry, you will understand it very clearly when
> you start unit testing your first large project.
Arrogance becomes you.
I've unit tested many large projects. It goes something like:
Object test= new Object(new OtherObjects);
ASSERT(test.goodness())
I simply use the mocks where necessary. If I am using factories or singletons then I tell the factory what to return for this test.
It's all quite simple.
|
|
|
Message #235703
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Vindication!
Ah, Bill... you had to do it didn't you. I know you included the little winking smiley and all but you know this is just going to start a pro-Spring rampage.
|
|
|
Message #235707
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
If startup time is 5 or 30s for an application that I start once a year or month is really of no interest.
Furthermore, in my experience Spring context startups tend to be slowed down by... Hibernate, the most.
|
|
|
Message #235712
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ah...the quarterly anti-Spring post...
summer is officially here. This is how you know you are number 1. Someone devotes an entire, usually inaccurate post about why you suck or they won't use you.
If only people devoted as much time to crafting a solution as pointing a finger.
What do *I* think? How about writing something that does the job better since you have all the answers.
|
|
|
Message #235713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ah...the quarterly anti-Spring post...
summer is officially here. This is how you know you are number 1. Someone devotes an entire, usually inaccurate post about why you suck or they won't use you.
If only people devoted as much time to crafting a solution as pointing a finger.
What do *I* think? How about writing something that does the job better since you have all the answers.
If you look at his other post, he thinks GUICE does the job better.
|
|
|
Message #235714
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Increasing Spring's Startup Performance
If startup time is 5 or 30s for an application that I start once a year or month is really of no interest.
This is of no interest when you're starting an application. But when you're testing this SUCKS. It means it takes longer to make changes. It also takes longer to run integration tests/builds.
With that said, the latest Spring 2.0.5 release includes some performance improvements , so try that out (including one I found which cuts out a lot of time if you have a lot of files - yay for me).
Some general tips to making spring go faster:
- Reduce the number of configuration files
- Don't use classpath*:*.xml type wildcards
- Reduce your number of beans - just because you can make it a <bean> doesn't mean you should.
- lazy-init="true"
- Turn off validation (Alternately: anyone want to rewrite Xerces?)
I was profiling our app startup the other day. About 33% of the time is in Introspector.getBeanInfo() so its really not all Spring's fault IMO :-)
|
|
|
Message #235715
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Increasing Spring's Startup Performance
If startup time is 5 or 30s for an application that I start once a year or month is really of no interest.
This is of no interest when you're starting an application. But when you're testing this SUCKS. It means it takes longer to make changes. It also takes longer to run integration tests/builds.
Sure, but most tests can be setup without spring, as plain unit test should be done. And even if you want to use spring context in your tests, AbstractSingleSpringContextTests does cache the spring context across all tests if you use the same context resource descriptors.
A empty spring context is fast to start, and so is a context with not so many beans. There is no reason to start a context with all beans and dependencies wired up if you are doing testing.
/Magnus
|
|
|
Message #235720
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
Meh! What's with all the Spring bile? Rod is pleasant enough and Spring has done a pretty good job at cementing IoC as the design pattern of choice for the noughties.
It also does a pretty good job of making a great deal of IoC unfriendly libraries behave themselves (EJB's, Struts, etc.), which is always nice. The code is well written, documented and tested. They don't break backward compatibility and their core infrastructure has been able to adapt to various advances in IoC configuration like AOP, annotations, scripting etc.
Spring goes out of its way to play nice with other, sometimes more stuffy (Mr King *cough cough*) libraries. Their license is as friendly as it could be, the folks on the forum's are always helpful and the guys in charge are pretty good at not ripping into the competition at every opportunity (Mr Lee *cough cough*).
So, relax and enjoy. Spring'll get faster and easier to configure, I have no doubt.
|
|
|
Message #235721
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
the folks on the forum's are always helpful and the guys in charge are pretty good at not ripping into the competition at every opportunity (Mr Lee *cough cough*).
When have I ripped into Spring? (excluding that one time which occurred long before Guice even existed) :)
|
|
|
Message #235722
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Stink bomb
Nothing like lighting a stink bomb before we check out for the holiday (in the U.S. anyway).
I've got no problem with Arif's blog post and his opinions. He can use Guice or whatever works for his project. Spring happens to work great for us, but I am not going to argue for what Mr. Rachim should should use on his project.
What I do have a problem with is the ServerSide editors allowing this non-news to be accepted on the front page. How many times do we have to tread over this issue? Do we really have to ignite this again?
If Spring works for you, use it. If you want to bunk with the JBoss fellas, fine. Guice? Cool.
Next topic!
|
|
|
Message #235723
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This is a matter of "state"
Well, from my point of view XML configuration vs. annotations or integrating with third party libraries and having prectical and good templates is not the key point of Spring. Annotations will eventually replace XML metadata in any frameworks(indeed it already has), sparing that using XML as metadata has still its use where it is not coupled to a specific Java source file and application global such as in workflows, etc.. Having nice templates for third party libraries and frameworks is a very strong feature of Spring, and that's why I like it most. As for Ioc, I won't discuss its benefits. Especially in unit-testing. However, today, EJB3-JPA provides the same infrastructure as Spring does. So, I don't see an architectural difference there, they all depend and AOP and interception.
Spring's main point is that it is a stateless framework, and application state is always kept on HttpSession. This was obviously a better strategy than EJB 2.X Stateful session beans. So Spring was the best choice of the time.
Now, there's a new kid in town, Seam.. Although it is currently coupled to special technology base(JSF and EJB 3) it has a new architectural strategy. Seam puts its vote on stateful applications, and Stateful EJBs(Yes, the state can still be kept in HttpSession under the hood but the framework is completely designed to make this transparent to developer).. And, though I haven't tried seam yet in a real project, this main architectural point seems very reasonable to me...
We'll see what happens in the near future, but I think seam offers a better model for the time being..
|
|
|
Message #235724
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ah...the quarterly anti-Spring post...
I like the quarterly xxx sucks posting. Some of them illustrate the that emperor has no clothes. Some of them let others know that there are other possible solutions out there that can do some task better than xxx can. Others elicit responses that teach the community about ways to avoid problematic situations in xxx. And yes, some of them are just plain stupid.
Keep 'em coming!
John Murray
Sobetech
|
|
|
Message #235727
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
asphinctersayswhat?
Wow. Thanks for that Arif. When is your book out?
c:\>del /s c:\tools\spring
I wondered why we weren't getting on our project -- its because we use Spring.
|
|
|
Message #235731
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ah...the quarterly anti-Spring post...
summer is officially here. This is how you know you are number 1. Someone devotes an entire, usually inaccurate post about why you suck or they won't use you.
If only people devoted as much time to crafting a solution as pointing a finger.
What do *I* think? How about writing something that does the job better since you have all the answers.
If you look at his other post, he thinks GUICE does the job better.
Ah...so he wrote GUICE? :-)
|
|
|
Message #235732
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Increasing Spring's Startup Performance
If startup time is 5 or 30s for an application that I start once a year or month is really of no interest.
This is of no interest when you're starting an application. But when you're testing this SUCKS. It means it takes longer to make changes. It also takes longer to run integration tests/builds.
With that said, the latest Spring 2.0.5 release includes some performance improvements , so try that out (including one I found which cuts out a lot of time if you have a lot of files - yay for me).
Some general tips to making spring go faster:
- Reduce the number of configuration files
- Don't use classpath*:*.xml type wildcards
- Reduce your number of beans - just because you can make it a <bean> doesn't mean you should.
- lazy-init="true"
- Turn off validation (Alternately: anyone want to rewrite Xerces?)
I was profiling our app startup the other day. About 33% of the time is in Introspector.getBeanInfo() so its really not all Spring's fault IMO :-)
Why so many startups. Most of the time, you can use JVM hotclass replaces(at least I can) when I'm debugging and don't have to restart the app from scratch.
|
|
|
Message #235734
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
Arif...
I guest, you need "magic artifact" to make your Spring applications run with better performance.
|
|
|
Message #235735
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
I have to say I will happily subscribe to "Spring sucks" and "I won't use it". This however has nothing to do with Spring-the-framework.
As usual it's the people who wreck it. In my view Spring has significantly lowered the bar for skills. Many people who have embraced Spring did that for the only reason that they never understood or bothered to understand other technologies/frameworks (including EJB).
The general style usually used to introduce Spring - EJB sucks so use Spring - doesn't in fact do good service to Spring. People take Spring and then start piling up same old sh*$# only in the "Spring way".
I, personally, am most frustrated at places where EJB-based implementations, terribly implemented but actually working are being replaced by Spring ones, just for the sake of following the trend.
|
|
|
Message #235736
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
As usual it's the people who wreck it. In my view Spring has significantly lowered the bar for skills.
As did Java (vs C). And C (vs Assembly).
|
|
|
Message #235740
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Increasing Spring's Startup Performance
Most of the time, you can use JVM hotclass replaces(at least I can) when I'm debugging and don't have to restart the app from scratch.
Um... have you actually tried this? You can swap a class so long as only method bodies have changed. I hardly think tweaking a method body qualifies as "most" of the changes you're likely to make.
|
|
|
Message #235741
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
Another issue is that of the Golden Hammer problem - When the hammer is the only tool that you have, every problem seems like a nail.
I see a lot of projects starting small with very valid reasons of using Spring. But then the infection manifests - every one starts using Spring every where without evaluating if they NEED Dependency Injection in the first place. Reminds me of the long forgotten article by Martin Fowler - http://www.martinfowler.com/articles/injection.html
Service Locator is not something which is not out of fashion. IMO it saves a lot of that dependency configuration stuff in the first place.
Regards,
Mrinal
|
|
|
Message #235746
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Bill has a friend
Finally! Vindication! One person in the Java community finally agrees with me that Spring sucks.
Hani always doubted you had a friend ...
|
|
|
Message #235747
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
...In my view Spring has significantly lowered the bar for skills....
that's a good point, not a bad one ! would you prefer that the j2ee stack remains just for the very best people ????
...Many people who have embraced Spring did that for the only reason that they never understood or bothered to understand other technologies/frameworks (including EJB)....
i don't think so. i have been using the "standard" j2ee stack for years before switching to spring and i can say that, in order to use spring, you still need to understand in depth what is happening under the cover when you use a spring helper. do you really think that being able to write some copy&paste boilerplate code (for jndi lookup, for db connection, for example) gives you so much more understanding ?
|
|
|
Message #235748
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
There's a difference!
However, today, EJB3-JPA provides the same infrastructure as Spring does. So, I don't see an architectural difference there, they all depend and AOP and interception
What??? You don't see an architectural difference between Spring and EJB3? Think again, please...
EJB3 *is* an architecture while Spring in only a framework: With Spring you can use the architecture of your choice - with EJB3 you simply cannot.
Furthermore EJB3 uses a limited form of AOP while Spring uses a full one (or more than one AOP implementation if you want)
Daniele
|
|
|
Message #235749
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How hard is creating objects anyway?
I've never understood why creating objects is so burdensome that a complete other framework with a O(n) configuration burden is required. Just create the darn objects.
Don't worry, you will understand it very clearly when you start unit testing your first large project.
It is not only testing, if you have to work with simulated modules because some third party is not on time, or the schedule demands some work with dependencies into not yet existing code, this is also heavens sent.
|
|
|
Message #235750
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: There's a difference!
However, today, EJB3-JPA provides the same infrastructure as Spring does. So, I don't see an architectural difference there, they all depend and AOP and interception
What??? You don't see an architectural difference between Spring and EJB3? Think again, please...
EJB3 *is* an architecture while Spring in only a framework: With Spring you can use the architecture of your choice - with EJB3 you simply cannot.
Furthermore EJB3 uses a limited form of AOP while Spring uses a full one (or more than one AOP implementation if you want)
Daniele
Well the borders nowadays are blurry, there are embedded ejb3 containers.
EJB3 first of all is just a specification whether it has to be a container or framework does not really matter.
I am personally happy the way ejb3 develops nowadayw with Seam.
|
|
|
Message #235751
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: helloworld-object.xml
http://docs.jboss.org/jbportal/v2.4/reference-guide/en/html/xmldescriptors.html
JBoss Portal provides an administrative UI to configure deployments. The xml descriptors are merely there as a developer resource.
Next time, do your homework before I have to chime in and make you look dumber than you normally do.
Don't worry, the XML is there, and it is so awful that it screams: you may have all the tools you want, but if you needed to document it, this means that somehow one has to deal with it. Ah, and of course don't forget to stay metal, general quality of the framework will benefit, and XML will write by itself.
On a more serious basis: Spring XML is not bad at all, and even if it were, there are a number of alternative ways to configure it (I prototyped a very quick way to configure a context in java in 2005, then didn't work on it anymore because it simply wasn't worth the effort: the XML config is absolutely good enough for the job, and java-based configurations tend to quickly not as structured and clean).
There are now a lot of different ways to reduce the xml or avoid it altogether, but monkeys jump up everywhere and keep babbling about "how awful" the XML configuration is: they almost never show equivalent examples using other tools, and when they do they normally produce some lame near-dsl-near-natural-language simulated by using flowing constructs which in my opinion are far uglier than the clean, structured, navigable syntax the XML allows (with the help of modern IDEs such as Idea and Eclipse).
So if your sport is to spot dumb people, look in that monkey camp: I'm sure you will find more palatable victims.
|
|
|
Message #235752
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: There's a difference!
However, today, EJB3-JPA provides the same infrastructure as Spring does. So, I don't see an architectural difference there, they all depend and AOP and interception
What??? You don't see an architectural difference between Spring and EJB3? Think again, please...
EJB3 *is* an architecture while Spring in only a framework: With Spring you can use the architecture of your choice - with EJB3 you simply cannot.
Furthermore EJB3 uses a limited form of AOP while Spring uses a full one (or more than one AOP implementation if you want)
Daniele
Ueh! Ti ho convertito? :)
|
|
|
Message #235753
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
the folks on the forum's are always helpful and the guys in charge are pretty good at not ripping into the competition at every opportunity (Mr Lee *cough cough*).
When have I ripped into Spring? (excluding that one time which occurred long before Guice even existed) :)
Not sure, but, uhm, here? http://crazybob.org/2007/06/lies-damned-lies-and-xml.html
|
|
|
Message #235754
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: There's a difference!
For sure, the difference is well known!
Anyway I cannot understand the problem:
You don't like Spring? Don't use it!
You like EJB3 (Oh My!) ? Good luck!
I think Rod Jonhson & Al. have done a great job with Spring.
Spring has been the best innovative java software of the past 5-6 years.
And now there is not yet another great innovative idea below the horizon.
But, of course, every thing is perfectible, and nothing is perfect.
But please, do not negate the evidence: Spring framework is a milestone for j2ee smart developers, while ejb3 framework is working so hard to be wild accepted.
IMHO, even if you don't like the Spring Framework, you should admit the benefit you have using it.
Bye
|
|
|
Message #235755
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How hard is creating objects anyway?
It is not only testing, if you have to work with simulated modules because some third party is not on time, or the schedule demands some work with dependencies into not yet existing code, this is also heavens sent.
Yes of course not, but considering the trollish nature of the post i was replying to i didn't feel like spending time writing an essay.
As a side note; one more use is assembling different versions/configurations of same software for different customers. I have not used Seam or Guice in real projects, but it seems to me that their approach might make this difficult, or at least somewhat 'unnatural'?
|
|
|
Message #235760
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: There's a difference!
Well the borders nowadays are blurry, there are embedded ejb3 containers.
EJB3 first of all is just a specification whether it has to be a container or framework does not really matter.
I am personally happy the way ejb3 develops nowadayw with Seam.
I'm sorry, but I have to disagree.
Sure, EJB3 is a specification, but the EJB3 specifications force the use of an architecture where the smallest distribution unit is an object.
It doesn’t matter if nowadays there are a lot of EJB3 embeddable containers: in any case you heavily depend on the EJB apis and that architecture.
|
|
|
Message #235761
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: There's a difference!
Diciamo che hai dato il... là ;-) bello, sto thread è diventato una chat per italiani :-D
|
|
|
Message #235763
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Old Wine In New Bottles
I think the comparison is nothing but Old wine in New Bottles and yes Spring has outlived all these hollow comparisons.
Thanks,
Franklin
|
|
|
Message #235764
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XML wins
I agree with you! You can try every other configuration method but you'll return on XML to configure your projects! According to me, annotations and the declarative programming is just the Chimera of modern software engineering. Embedding configuration options stucked with code is not the right solution in large projects.
|
|
|
Message #235772
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spring critics
I have yet to meet one single developer who actually used Spring in a real project, coming back and telling me that Spring "sucks" (anybody in this thread? that would be a first).
All the Spring critics I've seen so far, are people telling us they won't use the framework, without having fully investigated the whole thing. Like Mr Rachim.
For example, the constant moaning about the "XML-hell" aspect of the framework has been addressed many, many times. Short answer is : there are other alternatives to XML configuration in Spring.
Maybe it's too much to ask, but people would do themselves and others who might read them, a favor by refraining from writing about subjects they haven't fully researched.
Just some thoughts.
|
|
|
Message #235777
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring critics
there are other alternatives to XML configuration in Spring.
While this is true, I tend to go farther and directly state that Spring XML config does not suck AT ALL: not only it is a clear - and structured - way for expressing what it does need to express (a structure), but also it offers a number of features allowing reuse of definitions through composition or inheritance, modularization by means of context separation (direct imports or xml context aggregation), syntetic definitions through tag handlers which may be considered a way to impose "sensible defaults" which may be overridden by reverting to normal bean configurations, etc.etc.etc.
With the support offered by modern tools such as Eclipse SpringIDE or IDEA we now have refactoring capabilities, cross-searches of usages, navigation features, various analysis, and so on, bringing a nice, simple, consistent tool to an almost perfect state for what it does need to do.
Isn't this some sort of "duplication", given the fact that a java configuration system automatically gives all of this? Maybe, but I think that the structure that the XML naturally induces is not bad at all, for a configuration system: I experimented with various styles of java configuration and wasn't particularly attracted by any of them.
More than that: I never really feel the need of anything more than what I have with Spring. This is why I tend to get irritated when I read that "Spring sucks" or "Spring API is not usable": this is simply not true at all. It may MAYBE made better, but there surely isn't any positive revolution on the horizon, yet.
Assimilating the "Spring vs Guice" comparison to the "Struts/EJB2 vs all-the-nice-things that came after" one is surely a good marketing try, but is completely off-target: Spring is not Struts 1, nor EJB2, and moreover Spring IS a lot of those "nice-things-that-came-after". Prove your value, then have the world recognize your value, then you will be able to say that "Spring sucked". Up until now, I only see annotation configuration, more dependencies and invasiveness, and unstructured java configurations in a quasi-descriptive language which do not give value at all to solve the hardest problems we are facing these days (GWT does, in a smart way, for instace: this is real innovation).
In short, what is important for a tool such as Spring XML configuration is that it offers a clear, simple, and powerful set of tools to enforce best practices, and to obtain nicely organized structures of modules (application contexts). Having said that, if a team does NOT use those tools, this surely as hell means there will be a lot of incredibly dumb and verbose XML: but I think there is not a single tool in the world that prevents idiotic use or abuse.
|
|
|
Message #235780
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring critics
Well said. I also tire of the "XX sucks" crowd when they're talking about things that work. They're people who think that crowing loud or going against the grain FOR ITS OWN SAKE is somehow noble. "Stop drinking the koolaid" is a big thing you'll hear out of them, even when you're being perfectly reasonable about why you support something, because it gives them a thrill to be some kind of iconoclast, and implicitly superior to the poor huddled masses.
Sorry to get psychological, but this kind of flamebaiting of Spring is tired. You know why people said "EJB2 sucks" or "Struts sucks"? Because they did. There were lots of tiresome problems with them that got in the way of actual productivity and didn't make sense. At the time Spring was created, you could point to it as an alternative to Spring not because it was just different, but because it grew directly out of experiences with EJB2 and other technologies. There were specific pain points that were addressed. It became popular on its own merit, not simply because it was the big new thing (I'm looking at you, ROR).
Is there room for improvement? Sure, as there is with anything. But just hopping on a "Spring sucks" bandwagon without really understanding why (maybe you just didn't "get it", though there isn't much to get; maybe you are a natural contrarian; maybe you have a vested interest in Spring not succeeding so that your product does **cough jboss cough**) or ADMITTING why is just poor form.
Man, why do I find myself missing the days when I could contribute something to this board other than a fed up blast of these flamebait posts? back in the day there was actual useful discourse here. Now there's so much noise that I only find it worthwhile to contribute when I get really angry by stupid flames. Sigh....
|
|
|
Message #235783
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
Well, I've been hearing great news about spring though I have never had a chance to work with it until recently when I wanted to evaluate.
I did not understand why the MVC configuration itself has to be that complicated. I felt, struts did a good job at it.
When it comes to the bean configuration, i feel XML based configuration makes is more clumsy. Also, the option of combining it with unit test configuration makes it more and more difficult. But my basic question is, such bean configuration being something that get rolled off to production environment who would on the world would like to keep the unit testing configuration as well in it. I felt it's so stupid (I am sure there must be a way around to get rid of unit-test configurations when it gets rolled into production).
If you have had some experience with ATG, you would agree with me that how elegant such bean (atg components) configurations are - what spring achives in the name of IoC is what done in ATG world as well.
AFAIK about spring MVC, in my opinion, is not living up to it's braggings.
I also felt, I would love to spring to develop my lab projects for fun or something.
Spring framework is still in my list as potential framework to migrate our enterprise applications though.
--
panfox
|
|
|
Message #235785
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
To my experience, Arif is very right. Period!
We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction.
Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate. The current trend is that developers simply turn every single Java class into a Spring service. More specifically, every class is turned into a set of getters and setters. The latter simply breaks the object oriented design principles. Classes must have clear and precise interfaces. A lot of getters and setters is simply a bad idea!
|
|
|
Message #235787
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
To my experience, Arif is very right. Period!
We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction.
Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate. The current trend is that developers simply turn every single Java class into a Spring service. More specifically, every class is turned into a set of getters and setters. The latter simply breaks the object oriented design principles. Classes must have clear and precise interfaces. A lot of getters and setters is simply a bad idea!
And exactly how is Spring forcing you to use setters and getters?
You run a large project without well defined design rules of what should become a spring bean, how to use setters and getters etc, and then you blame Spring for failing?
/Magnus
|
|
|
Message #235788
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Increasing Spring's Startup Performance
Most of the time, you can use JVM hotclass replaces(at least I can) when I'm debugging and don't have to restart the app from scratch.
Um... have you actually tried this? You can swap a class so long as only method bodies have changed. I hardly think tweaking a method body qualifies as "most" of the changes you're likely to make.
Um...yes I have actually used it. I wouldn't talk about if I didn't use it and I'm well aware of its limitations.
I don't tend to add many methods when I am *debugging*.
|
|
|
Message #235789
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
To my experience, Arif is very right. Period!
We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction.
Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate. The current trend is that developers simply turn every single Java class into a Spring service. More specifically, every class is turned into a set of getters and setters. The latter simply breaks the object oriented design principles. Classes must have clear and precise interfaces. A lot of getters and setters is simply a bad idea!
Don't blame the tool, blame the user and speak for yourself. You used Spring inappropriately and you turned every class into a service.
Just because you cannot drive and wrecked your car doesn't mean the car is a poor invention. Perhaps you need to pass the road test instead of just getting behind the wheel.
|
|
|
Message #235791
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
"Don't blame the tool, blame the user and speak for yourself. You used Spring inappropriately and you turned every class into a service."
You obviously did not read my text. I said: "Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate". And then I said: "The current trend"
I would personally never make every class to a Spring service, but that is what was done by several experienced Java developers.
Just that you have learnt Spring, it does not necessarily qualify you to be a good driver.
|
|
|
Message #235792
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: helloworld-object.xml
Don't worry, the XML is there, and it is so awful that it screams: you may have all the tools you want, but if you needed to document it, this means that somehow one has to deal with it.
I agree. In my car, the motor is there, and it is so awful it screams: I may have all the wrenches I want, but if Toyota needed to document it, this means that somehow I have to deal with it.
.. or I can just focus on driving while using the clever "user-interface".
|
|
|
Message #235793
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
Funnily while seemingly disagreeing with me you are in fact re-enforcing the exact points I made.
You say with Spring "you still need to understand in depth what is happening under the cover". Exactly, and those who do - benefit and deliver. I am more than sure that these people would have done well with "standard" j2ee stack. Unfortunately from my experience "many people who have embraced Spring" do not understand. With the "standard" stack they would have evolved - either learned or failed and disappeared into oblivion. With Spring - they linger on longer.
Yes, I want the very best people to use J2EE stack. Dumbing the technology down (and I mean this in an abstract context, not Spring one) scores extremely low on my list of values.
|
|
|
Message #235798
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring critics
In addition to the general XML sucks complaints about Spring, it seems those vested in some competing containers have issue with Spring. That fact that Spring can contain or be contained makes it flexible, integratable and hard to compete against. It's like a Java VM on a Windows OS, MS can't kill it.
IoC is a great pattern that people should be using whether the implementation is homegrown, Spring or something Guicier. Currently, Spring hits a sweet spot and gives many a face-saving, bloodless path and argument out of EJB-think. As for XML, Spring provides multiple strategies to wire your system so the XML argument seems like noise.
Despite this looking like a stupid TSS post it's good to test the argument of even realy good technologies now and then.
|
|
|
Message #235805
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: jyog sucks
xml configuration realii sucks,
Your level of spelling and level of intelligence has really been demonstrated by that post. Congratulations
|
|
|
Message #235806
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
As some has already mentioned xml configuration is not the only way to use spring. Annotation and Java configuration classes are available. To be honest there isn't a problem with using xml configuration as long as you plan/design it properly. It's really getting old news now for not using Spring because of xml configuration.
Spring allows easier J2EE/Java EE development with new features/sub-projects soon to be available. I cannot see why some people are so against using Spring....finally have we not had this debate quite a few times already?!
|
|
|
Message #235810
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: helloworld-object.xml
or I can just focus on driving while using the clever "user-interface".
Which of course is what you can do with Spring ides, also. ;)
By the way, I guess you have nice user interfaces for configuring things like jboss-cache, jgroups, the mbeans microkernel and things like that? It seems to me you have a fair amount of XML config, for being XML-config-bashers. And your XML config is generally far,far,far,far uglier than what is possible with Spring 2.1.
|
|
|
Message #235812
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
To my experience, Arif is very right. Period!
We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction.
Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate. The current trend is that developers simply turn every single Java class into a Spring service. More specifically, every class is turned into a set of getters and setters. The latter simply breaks the object oriented design principles. Classes must have clear and precise interfaces. A lot of getters and setters is simply a bad idea!
Of course, when I was saying that I've never met an actual Spring user complain about the framework, I was referring to people who have a minimum set of skills as of application design...
I do realize that the above comment appears as inflammatory, but, since I have zero tolerance for programmers who can't program, take it anyway you want it.
|
|
|
Message #235813
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
DI
I think DI can be separated on 2 parts:
1. Hard dependency. Between objects that will not be modified in future( static dependency )
For this type we using Java config classes and annotation
in code for clearness.
2. Soft dependency. Changeable part of dependencies(dynamic).
We use this for replace dependency externally
( replace real service with mock for example , change
property value from one property to another for example).
Combining these two complementary parts we can build
great applications IMHO.
Spring contains all of these.And I like it, because
for big applications I can combine both of these and
for small choose only one preferrable at this moment.
Just my 2 cents.
Thanks Spring Developers for Great Integration Framework.
p.s.
Sorry for bad english.
|
|
|
Message #235815
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
To my experience, Arif is very right. Period!
We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction.
Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate. The current trend is that developers simply turn every single Java class into a Spring service. More specifically, every class is turned into a set of getters and setters. The latter simply breaks the object oriented design principles. Classes must have clear and precise interfaces. A lot of getters and setters is simply a bad idea!
Don't blame the tool, blame the user and speak for yourself. You used Spring inappropriately and you turned every class into a service.
Just because you cannot drive and wrecked your car doesn't mean the car is a poor invention. Perhaps you need to pass the road test instead of just getting behind the wheel.
I second this opinion i have used spring in about half a dozend projects by now, and turning every class into a service is the worst decision you can make. I personally made the best experiences with IOC if used on a rather high level as binding glue between the layers.
Which means, view layer -> spring beans, bo -> spring beans -> dao spring beans, but nothing else except maybe some aop constructs which are bound to the layer beans.
Everything else in between is hard linked.
That way you only have to touch the configuration ocasionally it does not become overly bloated but you still can work with simulated layer objects etc... all the stuff which IoC can help you with.
Spring is a hammer, that does not mean you can repair everything with it.
|
|
|
Message #235840
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How hard is creating objects anyway?
I think you not getting the mood. You concern with your design and let the framework do creation and the wiring. When you work in a medium or large project you can reduce the pains of initial startup and object creation and make it in an elegant way.
|
|
|
Message #235841
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ah...the quarterly anti-Spring post...
summer is officially here. This is how you know you are number 1. Someone devotes an entire, usually inaccurate post about why you suck or they won't use you.
If only people devoted as much time to crafting a solution as pointing a finger.
What do *I* think? How about writing something that does the job better since you have all the answers.
And just to mention: you can choose which framework (or no framework at all), it's a free world.
|
|
|
Message #235848
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How hard is creating objects anyway?
> When you work in a medium or large project you can reduce the pains of initial startup and object creation and make it in an elegant way.
What is more elegant, one place where you can actually see how your application is wired together in code, or hundreds of xml files scattered across a file system? Your system should be in the code.
|
|
|
Message #235853
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
"Don't blame the tool, blame the user and speak for yourself. You used Spring inappropriately and you turned every class into a service."
You obviously did not read my text. I said: "Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate". And then I said: "The current trend"
I would personally never make every class to a Spring service, but that is what was done by several experienced Java developers.
Just that you have learnt Spring, it does not necessarily qualify you to be a good driver.
Oh, I read your text
"We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction."
*You* ended up with an ugly result.
*You* spend countless hours figuring out a problem most likely caused by your ugly result.
If your result was ugly, the most likely cause was you and your inappropriate use of Spring. Ayou've shown, learning it doesn't qualify you to be a good driver.
*Your* developers made mistakes and you are blaming the tool.
Don't blame the car for the drivers inexperience.
|
|
|
Message #235854
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How hard is creating objects anyway?
> When you work in a medium or large project you can reduce the pains of initial startup and object creation and make it in an elegant way.
What is more elegant, one place where you can actually see how your application is wired together in code, or hundreds of xml files scattered across a file system? Your system should be in the code.
???? Who has hundreds of XML files vs. hundreds of class files? You?
I'd love to see that uberclass! :-)
|
|
|
Message #235855
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How hard is creating objects anyway?
hundreds of xml files scattered across a file system
Hundreds? Scattered? Please.
"your system should be in the code": the xml config is a way to express structure, your system is in the code, its structure in the xml config. I don't know if xml is "elegant": what I'm pretty sure of, is that there is no way to write code in java that defines a structure in a more "elegant" way.
In my view an algorithm implementation may be elegant, a class structure may be elegant: the declaration of a structure is hardly something where you may put the intellectual value that qualifies something as "elegant".
XML for defining structures is not bad: the myth that XML configuration is a hell stems from having lots of different configuration files from different technologies, with different documentations, different approaches, different implementations, different locations and so on. This depends on the particular nature of java development, often made of different technologies assembled together.
What spring did, in this context, was to offer a path to a way to have all those different technologies be wired together and configured in an homogeneous way. At the beginning of our project we defined a location in our webapps where ALL the configuration files must reside, and we stick to it: it's not "scattered", it's in WEB-INF/cfg. If a technology forces us to put config somewhere else (WEB-INF/classes) we don't use it, period.
If a technology force us to use their particular configuration without being able to be configured by spring, we look at it with suspect.
When we started using spring for wiring struts actions, we quickly realized that it's unpractical having to provide duplicate bean definitions for every action: so we agreed on an autowire strategy and coded a simple extension so that we can override particular beans.
If you think you have to write thousands of configuration files if you use spring, you're wrong: you have to write thousands of config files only if you don't have a clue, but Spring has no part in it.
XML is not bad. If you don't like it, just use one of the other configuration styles (java, annotations).
|
|
|
Message #235859
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How hard is creating objects anyway?
> XML for defining structures is not bad:
Are they typed check? Do they show up in the code? Are they refactorable? Do I know where they are in the file system? How do I tell what all the magic elements mean or do?
That's all bad to me.
> If a technology force us to use their particular configuration without being able to be configured by spring
Then it seems spring should just be folded into the language because there is not allowed deviation.
> If you think you have to write thousands of configuration files if you use spring
Either there's so much to configure you need help or there's so little that you don't.
|
|
|
Message #235862
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Please show some code?
It would be helpful if someone could show some code that demonstrated the benefits. Do you have some that makes it clear ? I simply don't see when using springified projects.
|
|
|
Message #235899
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EJB3 - Spring - Architecture or not
Hmm.. Yes, I do agree with you on one point.. Maybe it's because nowadays no one can clearly say what an architecute is.. On my side, I prefer to be practical and not go into deep arguements about buzzwords.. Yes, with Spring, you can use the "techonlogy, or API" of your choice.. And that is also what I specially pointed at.. One of my favorites in Spring.. Personally, I like Spring. I find it clever and use it with pleasure.. And EJB3 has learned so much from both Hibernate and Spring in the right direction, but to agree with you, with some limitations and lock in... However, my point of view from architecture was; EJB 3 bears the same philophy under mind, the lessons learned from Spring and Hibernate.. That's nothing new.. The interesting thing to be emphasized here is the conceptual difference between Seam and Spring. Or the conceptual difference between stateful and stateless "architecture" from the end user(end programmer) point of view..
|
|
|
Message #235927
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: [Name]: [Number] Reasons I think [Action | Emtion] [Product]
Come on. This must be the worst post so far this year.
Well, that's certainly not for a lack of competition .. ;-)
Peace,
Cameron Purdy
Oracle Coherence: The Java Data Grid
Tee hee.
There is something to this. Where have all the good bloggers gone? Seriously between this, the JEE 6 spat, and the SOAP article I might just have to cancel my subscription.
|
|
|
Message #235953
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Please show some code?
It would be helpful if someone could show some code that demonstrated the benefits. Do you have some that makes it clear ? I simply don't see when using springified projects.
Then don't use it. If you don't understand it, don't use it. You wouldn't put a gun in your mouth, right?
However, a gun pointed at your enemy is a powerful weapon.
IMO, the usefulness of Spring is pretty obvious. Check out that old Introduction to the Spring Framework paper hosted on this site. If, after reading that, you don't agree with Spring's philosophy, then it simply isn't the tool for you.
However, there are plenty of people who *do* understand it and use it.
|
|
|
Message #235954
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How hard is creating objects anyway?
> XML for defining structures is not bad:
Are they typed check? Do they show up in the code? Are they refactorable? Do I know where they are in the file system? How do I tell what all the magic elements mean or do?
That's all bad to me.
> If a technology force us to use their particular configuration without being able to be configured by spring
Then it seems spring should just be folded into the language because there is not allowed deviation.
> If you think you have to write thousands of configuration files if you use spring
Either there's so much to configure you need help or there's so little that you don't.
Yes they are refactorable. Yes, you get errors if you try to inject something that isn't of the right type. If you are using the XML and you don't know where it is, the fault lies in you, not Spring.
Again, if you think you need thousands of configuration files, you don't understand the technology and are wise to avoid it.
|
|
|
Message #235978
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How about this for benefits
Here's one huge benefit of spring:
public interface MyServiceDao {
@Transactional(propagation=Propagation.REQUIRED)
public void addMyObject(MyObject myObject);
}
public class MyServiceDaoImpl extends HibernateDaoSupport {
public void addMyObject(MyObject myObject) {
getHibernateTemplate().save(myObject);
}
And in your spring beans file:
<bean class="MyServiceDaoImpl"
p:sessionFactory-ref="sessionFactory" />
<tx:annotation-driven />
"Magically", your dao has proper transaction management, jdbc/hibernate resource handling, etc....
Think of all the code you'd be writing to handle transaction management by hand, especially jta based transactions.
The power of spring is not entirely in the IOC container. There are many IOC containers available which can do the job (hivemind, guice, picocontainer). It's the integration points with things like Hibernate, JPA, JTA, JNDI, AOP (aspectj and aopalliance), etc... that give it the most power.
Any of these IOC containers can be abused by turning everything into managed beans. You use managed beans where they make sense, such as integration points between layers of your application (dao, service, ui, etc...) and where alternate implementations may be provided.
Spring is a great framework, and yes, there are things that could use improvement. That being said, Rod and co are very good at listening to feedback and actually acting on it.
If spring doesn't work for you, don't use it. Use what works best for your project.
|
|
|
Message #236027
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How about this for benefits
Matthew, for what it's worth, Guice supports @Transactional, too. You can use Spring's implementation directly (and many people do).
|
|
|
Message #236098
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
Arif doesn't know what he's talking about.
|
|
|
Message #236124
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
"Don't blame the tool, blame the user and speak for yourself. You used Spring inappropriately and you turned every class into a service."
You obviously did not read my text. I said: "Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate". And then I said: "The current trend"
I would personally never make every class to a Spring service, but that is what was done by several experienced Java developers.
Just that you have learnt Spring, it does not necessarily qualify you to be a good driver.
They skip OO programing and leapfrog right into SOA, the promising land.
|
|
|
Message #236129
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
Five reasons for not choosing for Spring is not a lot.
Based on my personal experience I can find many more reasons for all the other frameworks out there for not using them, starting with EJB3 Session Beans.
So the question is: what's the better alternative?
I'm using Spring already for years - in small and big projects - and it simply works for me.
|
|
|
Message #236323
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: There's a difference!
Furthermore EJB3 uses a limited form of AOP while Spring uses a full one (or more than one AOP implementation if you want)
Daniele
That is not true,
Spring uses a subset of aspectJ and you need to allways remember that is uses proxy for AOP implementation.
AspectJ or AspectWerkz are full AOP implementations.
Spring and EJB3 are proxy based, that solve almost all the problems, but give you one more problem.
you need to remember that they are proxy based.
|
|
|
Message #236324
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
Oh, I read your text
"We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction."
*You* ended up with an ugly result.
*You* spend countless hours figuring out a problem most likely caused by your ugly result.
If your result was ugly, the most likely cause was you and your inappropriate use of Spring. Ayou've shown, learning it doesn't qualify you to be a good driver.
*Your* developers made mistakes and you are blaming the tool.
Don't blame the car for the drivers inexperience.
Spring and DI does not make nothing ugly, the only problem is the big configuration files in big projects, but since the time I started the Spring-Annotations project, you can reduce a lot this configuration size.
and now it is being implemented a similar feature in the core of the spring-framework, what will make it easy for any one to use.
but I have to agree, big XML configuration files are difficult to read and maintain, but you can always break it into smaller modules.
|
|
|
Message #236327
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Arif Rachim: Five Reasons I think I won't use Spring
Just one last post.
I think all the reasons are valid, but there are a lot of reasons for "why to use spring" too.
nowadays you do not need to write all your configuration using XML, you have Spring Java Config, @Component and @Autowire, and http://sannotations.sourceforge.net project as alternatives.
if you want a scripting language, you have Groovy SpringBuilder.
and I think that the main thing about this post is that "there is no silver bullet".
Spring is a great framework for lots of situations.
I use it for years.
but I think that there are situations where it does not fit.
one of the responsibilities I have as an architect is to analyze each project, and tell what is the best technology, framework, language, combination of ..., for the project.
Most of the projects I have used java.
almost all java projects I used spring.
but some projects did not used java.
and some java projects did not used spring.
yes, spring is great, java is great, but you do not have to embrace a technology or a framework and use it all the time, you need to analyze every situation and choose what is best for that situation and that client.
well, at least this is my opinion.
|
|
|
Message #304942
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
not so fast there Bill Burke (EJB 3.0 O'reily book author)
so what if someone agrees with you that spring sucks. EJB 3.0 isn't good either. Whatever happened to just writing a class and using servlets? Elephant in the room. You really do not need a framework even for large projects. There is just too much hype these days. Gotta read through all the marketing bullshit and hype such as "Open source", "community driven", "Enterprise level", and other shit like that which makes you want to adopt a technology.
|
|
|
| MessageMessageMessage |
|
|
Thank you for replying to a message on TheServerSide!
Your reply has been successfully posted.
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
