Re: [Springframework-developer] about closing bean container

[<rn...@co...>]

I have a class that is responsible for creating a 
ClasspathXmlApplicationContext and allow access to it as a 
ApplicationContext.

Clients receive the ApplicationContext and ues the normal getBean() 
methods, etc. The originating class establishes the shutdown hook as it 
internally keeps the reference as a ConfigurableApplicationContext 
(since ClassPath... is both).

I only do this for legacy code where pushing dependencies in everywhere 
would be a problem. I don't like creating a factory for the Spring 
context (using the old static getInstance() pattern), but I'm 
constrained by current architecture.

So, in summary, the class that constructs your application context can 
create a shutdown hook right there, as you know it implements the 
close() method, everyone else should get a reference to 
ApplicationContext, because you don't want just anyone removing your 
singletons.

B.

Jozsa Kristof wrote:
> Ok.. and what about disposing the container's singletons from a shutdown 
> hook for non-web apps? If close() is not meant for the client view of 
> the context, than the server should take care about it imho.
> 
> dyn
> 
> jürgen höller [werk3AT] wrote:
> 
>> It's not in the ApplicationContext interface itself, because this is 
>> meant to be a client view of the context. Simply cast the context 
>> reference to ConfigurableApplicationContext; you can then invoke the 
>> close method there.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of Jozsa Kristof
>> Sent: Thursday, June 03, 2004 1:14 PM
>> To: spr...@li...
>> Subject: [Springframework-developer] about closing bean container
>>
>>
>> Hi,
>>
>> I started to wonder today why ApplicationContext interface doesn't 
>> include the close() method to dispose the singleton beans in the bean 
>> container. Is there any reason not to expose this method? On the other 
>> side, wouldn't it make sense to add a shutdown hook to clear up any 
>> still-existing bean containers at least on jvm exit?
>>
>> dyn
> 
> 
>