Accessing ApplicationContext / Beanfactory

Implementing ApplicationContextAware will give that bean access to the applicationContext. The code I was referring to was.

Code:

---

BeanFactory bf = new ClassPathXmlApplicationContext("applicationContext.xml");

---

OK, thanks, but do I see it correctly that solution 1) would create a second ApplicationContext as well?

If you mean using SingletonBeanFactoryLocator or ContextSingletonBeanFactoryLocator then no. I'd have a read of the JavaDoc and the reference manual for some more background information. Everything you need is on the original post. Likewise if you modify the code you posted it would work, it's just the former might be a cleaner solution.

Code:

---

        public static BeanFactory getBeanFactory() {
                if (_ctx==null){
                        LOG.fatal("Have no beanfactoy.... something must be wrong here");
                        throw new RuntimeException("Have no beanfactoy.... something must be wrong here");
                }
                return _ctx;
        }

---

Just wondering wouldn't it possible to create a FactoryBean which wraps your third party tool? That way you could inject your objects instead of looking them up each time.

Quote:

---

Originally Posted by karldmoore

If you mean using SingletonBeanFactoryLocator or ContextSingletonBeanFactoryLocator then no. I'd have a read of the JavaDoc and the reference manual for some more background information.

---

I disagree (but still not sure). Of course, if you use SingletonBeanFactoryLocator, it would use only one ApplicationContext, but the instance of ApplicationContext this Locator is using must be a duplicate.

like:

applicationContext.xml:

Code:

---

  <bean id="mainApplicationContext" lazy-init="true" class="org.springframework.context.support.ClassPathXmlApplicationContext">
      <constructor-arg>
        <value>applicationContext.xml</value>
      </constructor-arg>
  </bean>
</beans>

---

Ahhhh,... and a kind of proof is the lazy-init="true" because otherwise you would have and endless loop :D

Ok, got it.

I think we are talking at cross purposes, you're talking about applicationContext.xml, I'm talking about instances of the applicationContext. As in every call to new ClassPathXmlApplicationContext is going to create you a new instance.

Quote:

---

Originally Posted by mdeinum

Just wondering wouldn't it possible to create a FactoryBean which wraps your third party tool? That way you could inject your objects instead of looking them up each time.

---

As far as I understand you, it won't work.

For Example. Quartz can store jobs in the database. The Job is stored only with its full qualified class name. When it starts a new Job, it propably does something like

Code:

---

Class<name = Class.forName("com.example.ClassWithNeedOfInjection");
((Job)name.newInstance()).execute();

---

For Quartz we got already the solution that we can define our own factory and plug it into quartz. Now, we can get our jobs out of Spring.

Hibernate Validators does not support the possibility to plugin in a BeanFactory, so it instanciateit on its own. Thats why the ClassWithNeedOfInjection looks like:

Code:

---

class ClassWithNeedOfInjection implements Validator{
 
  ....

  isValid(Object o){
    UserDAO userDAO = (UserDAO) BeanfactoryAccessor.getBeanFactory().getBean("userDAO");
    ...
  }

}

---

I hope, I can express myself clearer :-D

Quote:

---

Originally Posted by karldmoore

I think we are talking at cross purposes, you're talking about applicationContext.xml, I'm talking about instances of the applicationContext. As in every call to new ClassPathXmlApplicationContext is going to create you a new instance.

---

We are talking nearly about the same thing ;-)

I am just saying that the SingletonBeanFactoryLocator is not as perfect as on the first look, since you have to create a new instance of the applicationContext to use it in the SingletonBeanFactoryLocator.

But ok. I really appreciate your and the help of the others. It helped a lot to understand all different solutions.

Thanks

Stefan