FactoryBean - Do created objects participate in container lifecycle as well?

[gemini929]

Hello,

If I have a FactoryBean create a given object, and the created object implements a given life cycle interface (LifeCycle, InitializingBean etc.), will the callbacks be called?

If not, is there a way to create a bean programatically and still expose it to the container callbacks?

[igm]

Hi,

there's a blog post covering the topic.

Just to quote the last paragraph to give an answer to your question:
"One important takeaway here is that it is the FactoryBean, not the factoried object itself, that lives in the Spring container and enjoys the lifecycle hooks and container services. The returned instance is transient - Spring knows nothing about what you've returned from getObject() , and will make no attempt to exercise any lifecycle hooks or anything else on it."

[gemini929]

To save people the reading, the puch line is this:

"One important takeaway here is that it is the FactoryBean, not the factoried object itself, that lives in the Spring container and enjoys the lifecycle hooks and container services. The returned instance is transient - Spring knows nothing about what you've returned from getObject() , and will make no attempt to exercise any lifecycle hooks or anything else on it."

With this in mind, is there a way to achieve both? I think programatically I can create a bean a register it with the applicationContext manually. This way, the context would know about it and all of the lifecycle methods would apply.

Is there an easier way to achieve the same?

[gemini929]

It would be nice if I was creating a singleton, to be able to specify a "target" bean name and have the factory also register the resulting bean with the current context.

I have to think this functionality has already been created somewhere...

[gemini929]

Just found this:

org.springframework.beans.factory.config.BeanRefer enceFactoryBean

I suspect that this is exactly what this is for...

[igm]

Just found this:

org.springframework.beans.factory.config.BeanRefer enceFactoryBean

I suspect that this is exactly what this is for...

I'm not sure about that. The doc says "FactoryBean that exposes an arbitrary target bean under a different name.". It exposes a bean that is already managed by a context (but under a different name).

[bytor99999]

I think we need to look at the design here. First, if you are using a Spring provided FactoryBean, then there won't be lifecycle things that we would even need to hook into here. For instance, the EmbeddedDatabaseFactoryBean. There isn't a lifecycle method that we need to hook into. I doubt any of Spring's FactoryBeans have a need for us to call a lifecycle method.

Now, if you create your own FactoryBean, then you might have something that needs to be called. But since you are writing this class, why not just call that lifecycle method in your getObject code. Or (why we need to look at our design) Why do we need to implement FactoryBean, we are tying ourself to Spring in that class and there is a perfectly clean way to do this with a POJO Factory class. The Factory would be configured as a regular bean where you can have lifecycle methods. And the bean that the factory creates will also be a regular bean where you can have lifecycle methods and tell Spring about them, say via init-method in our xml.

So there is a solution to any problem here. It just seems to be a problem because you want to create a class that implements FactoryBean, when you really don't have to. As a matter of fact a POJO Factory is much cleaner and more flexible. You can inject any bean or value into your Factory including passing beans/values to your factory-method via <constructor-arg>

Hope that helps.

Mark