Announcement Announcement Module
No announcement yet.
Integrating IoC into a service location ladden framework Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Integrating IoC into a service location ladden framework

    I'm trying to move my organization towards a more modern approach to building java apps. I want to use IoC, and more over, I want to have the ability to take advantgage of AspectJ.

    I have a very large code base that I can't really just abandon. Unfortunately all of this code base uses a service locator pattern. To make matters worse, alot of the code actually generates configuration at runtime to provide default values unless they were explicitly overriden.

    This really makes trying to find all of the effective configuration and spring-xml-ifiying it difficult. Also, I won't get buy off from the whole organization that moving things to a more standard config mechanism like spring is a good idea.

    At some point, someone realized that IoC would be pretty useful, so they made a very, *very*, naive implementation that was grafted into this old service locator config lookup code. Its there, but its poor nature really turns people off to use IoC since we really just can't use it effectively with what we have.

    Now, new code could be built using Spring, but at some point you must interface with legacy code, and thats where you get all kinds of integration problems. If you wanted to make a hello world application you'd have a mixture of spring, and the old static lookup garbage.

    I'd like to throw all that old code away and rewrite it - but thats just not an option.

    So this leaves me in a situation where I'm considering providing an alternate implementation for our custom service locator code that would actually delegate to spring instead of the old legacy config. Also, I'll have to provide an configuration adapter that would read our legacy config and translate it to something spring can use.

    This would let the legacy code bumble along doing its config generation and config look up thing, but still give newer pieces the ability to use spring and have everything all "sort" of integrated.

    Any expirence with this sort of problem?

  • #2
    Short answer ...

    Originally posted by scrop
    Any expirence with this sort of problem?

    I've had the same issues in an old J2EE application, where all the resources (session beans, entity bean homes, and the data source) are looked up using static methods that reside in a single service locator class.

    My approach has been to keep using the static methods in production, but to create ways for my test cases to inject these dependencies as well. For example, I might change a session bean that did this:

       public void doFoo() {
         ServiceLocator.getBarService().doBar();  // not testable e.g. if JNDI is used
    To do this:

      private BarService barService;
      public void ejbCreate() {
        // OK to call service locator as ejbCreate() is only called in production.
        // Still not testable, but who cares, as it's not likely to break
        barService = ServiceLocator.getBarService();
      // New setter added so test cases can inject this dependency
      void setBarService(BarService barService) {
        this.barService = barService;
      public void doFoo() {
         barService.doBar();  // now it's testable
    You can apply the same techniques to pretty much any class, even servlets or entity beans; you just have to tease the static method calls out of the code you want to test and into some production-only method (e.g. ejbCreate() in the case of session beans). Of course you have to ensure that your EJBs' properties obey the restrictions imposed by the J2EE spec (and you correctly passivate/activate them etc.).


    P.S. All that talking about "bar service" has made me thirsty!