Discussions

News: JL article on 'Spring: Working With Legacy Singletons'

  1. R.J. Lorimer has written an article for JavaLobby called "Spring: Working With Legacy Singletons," that addresses the use of Spring with the "classic" singleton pattern, injecting a singleton's factory (or the singleton itself) via Spring.
    Dependency injection, or inversion of control (IOC) as it is sometimes called, has certainly become an increasingly popular way to configure and engage applications that have wide, complex concerns. I can't speak for everyone, but for me, an application that has been built with IOC in mind is a beautiful thing. Everything is cleanly defined, and the code is just very simple. Sometimes, however, you can't fully adopt the dependency injection approach in applications. That shouldn't mean that you can't use it at all - it's just that sometimes chunks of an existing application may work a certain way, and it's too difficult/time-consuming to completely convert all of it.
    The article discusses some of the problems associated with factories in legacy applications, and how Spring can be configured to solve them. It's a fairly straightforward process, and highlights Spring's usefulness as an enabling technology.
  2. The article discusses some of the problems associated with factories in legacy applications,

    Does it? Can anyone direct me to some literature on why we should use Spring and not how to use it? I'm sure there are lots of benefits but I can't seem to find them listed in a concise fashion.
  3. The article discusses some of the problems associated with factories in legacy applications,
    Does it? Can anyone direct me to some literature on why we should use Spring and not how to use it? I'm sure there are lots of benefits but I can't seem to find them listed in a concise fashion.

    James,

    perhaps you might find this short article useful: http://www.onjava.com/lpt/a/5833

    Of course there are of plenty Spring resources on the net about Spring as well as technical books.

    Good luck.

    Dmitriy.
  4. The article discusses some of the problems associated with factories in legacy applications,
    Does it? Can anyone direct me to some literature on why we should use Spring and not how to use it? I'm sure there are lots of benefits but I can't seem to find them listed in a concise fashion.
    James,perhaps you might find this short article useful: http://www.onjava.com/lpt/a/5833Of course there are of plenty Spring resources on the net about Spring as well as technical books.Good luck.Dmitriy.

    To clarify, my question may come off like a I doubt the value of Spring. That is not the case. It has been recommended by many trusted individuals. My problem is that I don't have a clear understanding of my own to explain why we should use it to my boss and co-workers or even myself. I need a toe-hold to get started. I will check that link, thanks.

    Any recommendations on books?
  5. Just go to the website and look at the booklist there:

    http://www.springframework.org/bookreview

    or just search this site, there's a paper from Rod Johnson which give a good introduction to what Spring is and can do. It's called 'Introduction to the Spring Framework'

    I'd recommend 'Expert One-on-One J2EE Development without EJB' which is listed on the spring website for a good intro into what spring is and why you might want to use it.
  6. perhaps you might find this short article useful: http://www.onjava.com/lpt/a/5833.

    The article starts with really bad advise: using Spring’s HibernateTemplate.
    http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring
     
    If you use it, I suggest replacing it ASAP with better alternatives like this:
    http://www.onjava.com/lpt/a/5854
  7. perhaps you might find this short article useful: http://www.onjava.com/lpt/a/5833.
    The article starts with really bad advise: using Spring’s HibernateTemplate.http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring If you use it, I suggest replacing it ASAP with better alternatives like this:http://www.onjava.com/lpt/a/5854

    I think this is rather new development so you can't really blame Rod Johnson, but good info all the same. Thanks.
  8. I think this is rather new development

    Don't think so. I've been using HibernateTransactionManager for over a year.
  9. I think this is rather new development
    Don't think so. I've been using HibernateTransactionManager for over a year.

    Not that, the whole "hibernate hates spring" thing. I could be wrong but the blog is from august.
  10. Spring's Hibernate support[ Go to top ]

    FYI, Spring has been supporting Hibernate3's "SessionFactory.getCurrentSession()" operation (which was introduced as late as Hibernate 3.0.1) since Spring 1.2 final. This means that you can use Spring's HibernateTransactionManager, OpenSessionInViewFilter, etc while implementing your DAOs against plain Hibernate3 API, in "natural" Hibernate style. Of course this DAO style will also work with Spring's JtaTransactionManager.

    Hence, Spring's HibernateTemplate is effectively one but not the only option for implementing Hibernate-based DAOs. As one of HibernateTemplate's advantages over the plain Hibernate3 approach, it provides automatic conversion to Spring's generic DataAccessException hierarchy. If you prefer to have a well-defined exception hierarchy at your DAO interface level, not tying your DAO callers to a specific DAO implementation strategy even for exception handling, then HibernateTemplate is a convenient way to get this in a one-stop shop.

    We do follow our general framework philosophy here: Leave the choice up to the application developer. So the choice is up to you: Code your DAOs against Spring's HibernateTemplate or against plain Hibernate3 API. Spring's transaction and resource management will work nicely with both approaches, including the seamless switch between local and global transactions. Have a look at the ORM chapter in the Spring reference documentation, which indicates both approaches.

    For completeness, I'd like to point out that we support a similar level of choice for DAOs based on JDBC, TopLink, iBATIS SQL Maps, JDO and the upcoming JPA (Java Persistence API) as well. For Hibernate 2.1 and Apache OJB, on the other hand, we recommend to always use Spring's HibernateTemplate / PersistenceBrokerTemplate, mainly because there is no convenient native support for accessing transactional resources in the respective native API.

    Juergen
  11. Makes sense, singletons are problematic from a maintenance point of view, having it replaced with IoCed beans (Spring, Ejb3) makes really sense, due to the ability to be able to swap them in and out.

    Singletons as IoC beans probably is one of the few cases where I really prefer a central config file over annotations, you do not win that much by using annotations for application scoped beans compared to singletons, except that the binding is a tad lazier than with a singleton pattern.