Friday, March 12, 2010

Spring is totally losing its invisibility

Tagged with: , , ,
Tuesday, December 23, 2008, 8:00
This news item was posted in Notes category and has 14 Comments so far.

Many of you might remember at the spring 1.2.X series there is a strong voice like:

easy,quick configurations and implementations with spring

Yes in fact that was totally true. It really used POJOs as bean containers. And it works really fine. While using these spring versions you did not usually need to make any import statements for any spring package/class/interface
sample classes below were shown as best practices:

MyPojo.java

public class MyPojo{
public void initMe(){
//.. do something at startup
}
public void setMyService(MyService newMyService){
this.myservice=newMyService;
}
public void destroyMe(){
//.. do something at stop
}
}

MyFactory.java

public class MyFactory{
public void createNew(){
//.. do something at startup
}
public void setMyService(MyService newMyService){
this.myservice=newMyService;
}
}

In fact this feature speeds up the learning curve and makes the great framework totally invisible. But still you can also use some special and well organized interfaces and classes to benefit from some advanced features of spring like ApplicationContextAware, FactoryBean, InitializingBean

But now the best practice changed a lot and has more spring dependency then ever before. I just wonder, do you really use it like this ?

@Repository(value = "userDao")
public class UserDaoHibernate implements UserDao {
HibernateTemplate hibernateTemplate;
@Autowired
public UserDaoHibernate(SessionFactory sessionFactory) {
this.hibernateTemplate = new HibernateTemplate(sessionFactory);
}
public List getUsers() {
return hibernateTemplate.find("from User");
}
@Transactional
public void saveUser(User user) {
hibernateTemplate.saveOrUpdate(user);
}
}
@Service(value = "userManager")
public class UserManagerImpl implements UserManager {
@Autowired UserDao dao;
public List getUsers() {
return dao.getUsers();
}
}

source code from
http://www.slideshare.net/mraible/whats-coming-in-spring-30?type=powerpoint

Yes everybody knows, it is a result of effort to get rid of lots of xml files. But still is it the only way ?

Share and Enjoy:
  • Digg
  • del.icio.us
  • Netvouz
  • DZone
  • Wists
  • LinkedIn
  • Slashdot
  • Google Bookmarks
  • Reddit
  • StumbleUpon
  • email
  • Twitter

Related posts:

  1. DistributableEventPublisher for Spring via JGroups
  2. JGroups-Spring In Action
  3. who needs implementations?
  4. Java7 Wish: Object/Bean Factory
  5. light-weight distributed messaging via JGroups

You can leave a response, or trackback from your own site.

14 Responses to “Spring is totally losing its invisibility”

  1. mcakkan (mcakkan) said on Tuesday, December 23, 2008, 7:02

    Spring is totally losing its invisibility http://tinyurl.com/9xydmj

  2. opensourcereader said on Tuesday, December 23, 2008, 11:42

    What is great about spring, is that you have the CHOICE.

  3. John Smith said on Tuesday, December 23, 2008, 14:58

    Read the documentation. For every way that you use Spring where you have a dependency, you can use it where you don’t have one. If using the Template classes bother you, you can write the JDBC or Hibernate code by hand. If you don’t want the annotations, use XML.

  4. altuure said on Tuesday, December 23, 2008, 15:00

    hi john ,
    I have already knew the manual good enough
    but I just wonder how you use it ?
    you prefer xml or annotation configuration ?

  5. Artur said on Tuesday, December 23, 2008, 15:03

    Declarative configuration of behavior was always presented to me like a major benefit – “You don’t clutter the code with configuration/transaction/whatever details”, “Code is more readable”, “You can customize parts of the application without recompiling it”…

    Now, all the people and their dogs are switching to annotation-based configuration embedded inside source files – J2EE, Spring, AspectJ (probably others I don’t know about). Suddenly, having both parts of logic of application close to each other became important. Xmls are not longer so cool to edit by hand. What has changed ?

    I hate xml and I hate annotations when they are standing in the way of refactoring and debugging. After some time, many of xml configs started to get integrated with IDEs in the way of reacting to code refactoring changes. And around the time it started to work really proper, everybody is switching to annotations – and again, there are annotations with references to methods/variables/whatever or even worse, pieces of code (AspectJ annotations for example) which are plain, non-refactorable, not autocompleting strings. And what java has avoided to get into for many years (creating cryptic sub-languages for everything) is now shoehorned into non-fitting medium (string variables inside annotations).

    If somebody would propose “Lets allow mixing java with any strange language, inline, with any syntax you want”, people would cry and say somebody is trying to destory the language. But suddenly, if you don’t put this code into explicit blocks with proper syntax and support, just inject it into string variables on annotations, everything is ok…

    And somehow I feel that before we will get a proper support for everything in IDEs, there will be next ‘golden’ solution to all the problems.

  6. Dave Newton said on Tuesday, December 23, 2008, 15:16

    Meh. I still do most of my Spring configuration via XML to avoid the over-annotation issue (and because I have a tendency to use the same objects in non-Spring-ized apps, but that is on the decline).

    But let’s face it–if your app is set up to use Spring to its fullest you’ve already got a major dependency–adding the annotations isn’t really that much more of one.

  7. altuure said on Tuesday, December 23, 2008, 15:22

    yes that is point,
    I do not say ‘Spring kills XML’ or something like that,thanks to old version support of spring,
    I am talking about the trends and best practices

  8. William Louth said on Tuesday, December 23, 2008, 15:35

    This trend would not be so bad if such annotation class inclusions were standardized and not part of some proprietary (source available) solution.

    XML or Annotations you are still tightly coupled to the Spring @ runtime.

    William

  9. Nitin Reddy Katkam said on Tuesday, December 23, 2008, 16:11

    Hi!

    I’ve just started off with Spring.NET and, personally, I prefer to use XML files as changing the behavior doesn’t require me to re-compile and re-deploy code on the server. That saves me quite a bit of time.

    However, for development of really tiny applications, I would prefer annotations & attributes instead of XML.

    Not everyone would agree with me, but that’s free will :-)

    -Nitin

  10. Wesslan said on Tuesday, December 23, 2008, 17:48

    @Artur
    I get your point and I agree, to a certain point. I think annontaions clutter your code way less with “configuration/transaction/whatever details” than the old way of putting this information in Java code did.

  11. Solomon said on Tuesday, December 23, 2008, 19:42

    @altuure: check out the Spring JavaConfig project. The SpringSource guys pretty much agree with you that configuration should stay external to your main application code. They begrudgingly added the current version of Annotation based configuration based on customer pressure.

    @William Louth:
    Re: “if such annotation class inclusions were standardized” – they will be, for the most part, as part of the Web Beans JSR. The Spring Framework will support it when it comes out.

  12. James Arrington said on Tuesday, December 23, 2008, 20:37

    Aren’t you comparing apples to oranges? A plain POJO versus an “Entity” POJO…

  13. Peter Veentjer said on Wednesday, December 24, 2008, 9:58

    I see an applicationcontext as executable documentation. So even though XML sucks as syntax, I prefer it above annotations and autowiring because it describes how the components of your system are integrated. Moving it to sourcecode in the form of annotations imho is a bad practice..

  14. altuure said on Wednesday, December 24, 2008, 10:13

    when do you use annotation or XML ?

    If you are changing you database schema for any deployment you cannot use JPA annotations (although I don’t think anyone change its database schema)
    if you are using some external reference like JNDI,servletpath you should not use XML (another ‘best’ practice in Servlet API 3.0 and EJB API 3.1) in my opinion
    but for other cases that you can even use auto inject it can be preferred …

  15. moelholm said on Saturday, December 27, 2008, 14:55

    I think you have a very good point! I too never really liked compile-time dependencies to any proprietary framework/provider (@WebSphere…, @Spring… , and so on): It makes portability a pain and hurts your eyes if you are a purist.

    However, that being said – and as some of the replies already mentions – you are already tightly coupled to Spring even when you use XML based configuration.

    We better have to accept that both ways applies equally – the trend tell us anyways :)

Leave a Reply