Reading from CommonContext.xml

[Mike London]

I realize that the classes defined in CommonContext.xml get instantiated automatically by Spring, but I'm not sure how to get a hold of that instance.

What's the "Spring way" of getting a hold of a class that Spring automatically instantiates for me (that is with a BeanID or other ID) defined in CommonContext.xml?

Thanks in advance!!!

-- Mike

[Junilu Lacar]

In most cases, you wouldn't pull a class from the Spring context. You'd just let Spring "wire" your application components together via dependency injection (DI).

Here's what a traditional Java application would look like:

public class Foo {
   public static void main(String[] args) {
       Foo app = new Foo();
       app.start();
   }
 
   private void start() {
       Bar bar = new Bar();
       bar.doSomething();
       // ... and so on
   }
}

Of course, you'd probably need at least one "pull" from the context to start the application off (although it is possible to not have to do a pull at all). In a Spring-wired application, you might have something like:

public class Foo {
 
   private Bar bar;
 
   public static void main(String[] args) {
       BeanFactory factory = new XmlBeanFactory(
              new ClassPathResource("CommonContext.xml"));
  
       // pull instance of Foo from the context
       Foo app = (Foo) factory.getBean("mainApplication");
       app.start();
   }
 
   private void start() {
       // assume that Spring has already injected the
       // Bar instance we use here
       getBar().doSomething();
   }
 
   public void setBar(Bar aBar) {
       bar = aBar;
   }
 
   private Bar getBar() {
       return bar;
   }
}

In the above example, CommonContext.xml would define a bean of class Foo with an id or name of "mainApplication" and inject another bean of class Bar into its bar property. There may be more lines of code in the second sample but it is easier to reconfigure: simply change the CommonContext.xml definitions and restart the application.

Of course, in the real world you should always consider the likelihood of needing to change implementations so that it would actually be worth making the design like the second example. Another consideration would be testability. If Springifying a class makes it much easier to test, then I would also tend to do it.
[ May 06, 2006: Message edited by: Junilu Lacar ]

[Mike London]

Thanks!!!

Great example.

Mike