views:

502

answers:

2

I have already found a previous SF question regarding this issue and I believe setting the init-method and the destroy-method properties will be sufficient. But I wanted to hopefully ask the question a different way to further my understanding.

If I understand things correctly, a class that implements org.springframework.context.Lifecycle will behave different in a web app context (namely org.springframework.web.context.support.XmlWebApplicationContext) than in other application contexts? It will do this because the start() of the XmlWebApplicationContext (which will start the contained Lifecycle beans) will have been performed before the context configuration files are loaded.

Is this correct?

+1  A: 

I don't think so. The start() method is called by doStart() and both are in AbstractApplicationContext, which is the superclass of all application contexts. So there should be no difference.

Bozho
I saw and thought the same thing. I followed that code, but I never saw it being called in the web application. I'm trying to see if doStart() is called at all by the app context that is loaded in my app. I'll be trying more today and let you know.
Matt
+1  A: 

The Lifecycle interface should be implemented by beans that want to participate in the container's lifecycle. This is primarily intended to be implemented by the containers themselves (see docs here), although beans inside those containers can implement it also if they choose, and the start/stop signals will be propagated to them.

The start() and stop() methods are essentially notifications that the container has just started start, or is about to stop.

I'm struggling to find a good use case for this, for application components. Business objects should only be concerned with their own lifecycle, rather than with the container's lifecycle. One good reason why is when you use non-singleton scopes (e.g. request-scope) where the bean's lifecycle is independent of the container's.

skaffman
Thanks. The link you sent me to does not seem to indicate that Lifecycle is just for containers. It talks about it as a bean lifecycle. In fact I was not aware of the SmartLifecycle etc. I do agree with the more control an object has on itself the better, but with a lifecycle of an object is usually there because it doesn't control something.
Matt
@Matt: What I meant to say is that `Lifecycle` is only for the container *lifecycle*, not just for containers. Beans can participate in the container lifecycle if they choose, but that's a very particular requirement.
skaffman
@skaffman Thanks that makes more sense. So in the case of a web application and a XmlWebApplicationContext is the lifecycle of the container started before the bean definitions are loaded? Is that why I'm not seeing a start() called for my defined bean?
Matt