View Full Version : Refresh ApplicationContext
tw888
Nov 2nd, 2004, 09:43 AM
I am working on a web application that needs to dynamically change the configuration without restarting the application. Is it safe to call ApplicationContext.refresh() while the application is still running? It seems that refresh() does refreshBeanFactory() and then a lot more post processing. Potentially at the mean time a user request can trigger getBean() being called, which could generate unpredictable results. Are there any alternatives? Thanks.
Rod Johnson
Nov 2nd, 2004, 11:02 AM
Is it safe to call ApplicationContext.refresh()
No. However, there are some alternatives right now depending on what you need to do, and there will be more "dynamic" support in Spring 1.2.
What configuration do you need to change? If you can describe the requirements, I may be able to help. And it will be useful to help plan the 1.2 features...
tw888
Nov 2nd, 2004, 12:42 PM
Rod,
Thank you for your reply.
The configuration we need to change includes mostly properties of simple types (string, int, boolean, url, date, etc), such as server name, timer period, flags. It may also include collection types (list, map), such as list of outgoing notification emails, etc. So the abilities to modify simple type values and insert/update/delete collection values are important to us.
Can you also talk about the dynamic support in Spring 1.2 at high level?
Thanks.
Tongyu Wang
Rod Johnson
Nov 4th, 2004, 04:20 PM
The full scope of 1.2 dynamic features hasn't been finalized. However, one feature that may be of interest to you is the ability to source one or more "config" objects from the database. These objects would be mapped with an O/R mapping tool such as Hibernate or a JDO product, although there's also support for writing your own JDBC code. I think that this would meet your requirements, as it's possible to ask the "dynamic" object to refresh itself, or even to change its primary key. You could thus map with Hibernate/whatever an object that included multiple configs, other objects would depend on that object using Dependency Injection via its type, but the object will actually be a proxy, enabling its implementation to change behind the scenes.
See the tests for the org.springframework.beans.factory.dynamic.persist package, and the test.xml file for an example. Warning, this code is pre-alpha, and will probably change (hopefully to become simpler). However, that means feedback is most welcome.
jpoley
Jul 16th, 2005, 06:28 AM
did this make it into 1.2?
Colin Sampaleanu
Jul 17th, 2005, 11:49 AM
did this make it into 1.2?
No, unfortunately.
RogerMoore
Jul 18th, 2005, 09:03 AM
I want something even simpler, what I want to do is just reload the whole application context, it doesn't matter about any references to beans in the old app context getting stranded. Here is the problem: in my application context I get some RMI client beans, but every once in a blue moon, the RMI service is unavailable for various reasons.
I use the RMI beans at the end of a registration session, so once I detect a problem with the RMI, I can fix it, but I have no way of refreshing the RMI bean that I have found. applicationContext.refresh doesn't work for this, and I have even tried extending the ContextLoaderServlet, overriding the service method to call init(), and even that doesn't work! I still get the old RMI bean that says "org.springframework.remoting.RemoteConnectFailureE xception: Cannot connect to remote service..."
A VM bounce is not a possibility here b/c it is a production server with many (more important) apps that cannot go down during the day.
Can someone tell me anyway to do what I want. Even if I put in a property file a list of bean names to destroy and reload that would work, but how do I do this? Thanks!
RogerMoore
Jul 18th, 2005, 11:05 AM
I realized what I was doing wrong. In my controller I was using setter based injection for the RMI bean which is fine if it is always going to be there, but if the bean goes bad it will never look to the Factory for another instance of it. So I just go the factory every time for that bean now. I am still going to extend the ContextLoaderServlet though, just to give me a way of reloading everything if it didn't even come up, and I am not able to do a VM bounce. Thanks.
Powered by vBulletin® Version 4.2.1 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.