Accessing ApplicationContext / Beanfactory

[karldmoore]

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

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

[sneumi]

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

[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. 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.

	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;
	}

[Marten Deinum]

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.

[sneumi]

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:

   <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

Ok, got it.

[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.

[sneumi]

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

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:

class ClassWithNeedOfInjection implements Validator{
 
  ....

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

}

I hope, I can express myself clearer :-D

[sneumi]

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