File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

doubt in Spring : <bean ... init-method="" destroy-method="" ...>

 
Sidhartha Ray
Greenhorn
Posts: 29
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello everybody
I'm new in spring f/w.
I've a doubt in <bean> tag. I'm setting the "init-method" & "destroy-method" to some method(say start() & stop()).
Here the problem is, I'm finding start() method getting executed but the stop() method not, means even if I'm reassigning a reference or explicitly assigning null to it, the stop() method doesn't get executed.

Any idea ???
 
Jesus Angeles
Ranch Hand
Posts: 2068
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
you should post this in the spring forum.

what reference are you assigning null to? the appcontext? if so, it is not enough. call the context's close() method.
 
Bill Gorder
Bartender
Posts: 1682
7
Android IntelliJ IDE Linux Mac OS X Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By default Spring beans are singletons. They hang around for the life of the context. As Jesus said calling close on the ApplicationContext will cause these beans to be destroyed. Typically the destroy method is used to clean up a resource or close connections when the application is terminated. In most cases you wont need this.
 
Mark Spritzler
ranger
Sheriff
Posts: 17276
6
IntelliJ IDE Mac Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, the close() method isn't actually on the ApplicationContext interface, it is on the ConfigurableApplicationContext interface, so you will have to cast your ApplicationContext to this interface in order to call close() directly.

Note, if you use XmlWebApplicationContext in a web environment, then close is called automatically when you undeploy or shutdown your web container.

Mark
 
Sidhartha Ray
Greenhorn
Posts: 29
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all for your response...

coming to Jesus & Bill, I've made that bean's scope="prototype" & then assigning null to it & again also reassigning to it another new object, still the stop() method doesn't get executed........

coming to Mark, I'm not making any web application, it's simply an core java program & I'm creating appl context as,
ApplicationContext context = ClassPathXmlApplicationContext("hello.xml");
 
Jesus Angeles
Ranch Hand
Posts: 2068
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i think everyone will want to know what object are you assigning null to.

did you try the close method along with casting mentioned above?
 
Bill Gorder
Bartender
Posts: 1682
7
Android IntelliJ IDE Linux Mac OS X Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That is because the prototype scope is a little different. Spring does not manage the complete lifecycle of prototype scoped beans. It is the responsibility of the application code to do any expensive clean-up on these. Usually regular garbage collection is sufficient but if you have special needs for clean-up this has to be handled manually.

From the reference docs

In contrast to the other scopes, Spring does not manage the complete lifecycle of a prototype bean: the
container instantiates, configures, and otherwise assembles a prototype object, and hands it to the client,
with no further record of that prototype instance. Thus, although initialization lifecycle callback methods
are called on all objects regardless of scope, in the case of prototypes, configured destruction lifecycle
callbacks are not called. The client code must clean up prototype-scoped objects and release expensive
resources that the prototype bean(s) are holding. To get the Spring container to release resources held by
prototype-scoped beans, try using a custom bean post-processor, which holds a reference to beans that
need to be cleaned up.
In some respects, the Spring container's role in regard to a prototype-scoped bean is a replacement for the
Java new operator. All lifecycle management past that point must be handled by the client. (For details on
the lifecycle of a bean in the Spring container, see the section called “Lifecycle callbacks”.)
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic