Dynamic refreshing of application contexts [SPR-94]

[spring-projects-issues]

Rod Johnson opened SPR-94 and commented

Provide support or application contexts to be dynamically updated: for example, by a BeanDefinitionReader that periodically rereads an XML file or other definition format.

---

Affects: 1.2 RC1

21 votes, 17 watchers

[spring-projects-issues]

Jason Poley commented

What advantage do you have of using the file to "reload" why not do as Bea Weblogic does with its config.xml. Read once from file, and if it needs to be modified then do it thru the context and then mark it dirty and persist it back to disk (with option set on). This could be done with JMX (in container) or out of container. ?

[spring-projects-issues]

Rod Johnson commented

I guess this would be one way to do it, but I must say the WebLogic approach where the container writes back the XML has always irritated me. (Especially pre 8.1 where it would regularly corrupt the file.)

Also, what if it's impossible to write back to the definition? WebLogic is a top-level Java app, Spring is not. What if the definition is in an XML file accessed via the network?

Thanks for the input, and I'd like to pursue this discussion. Perhaps on the dev list?

[spring-projects-issues]

Jason Poley commented

its here http://sourceforge.net/forum/forum.php?thread_id=1115900&forum_id=250339

thanks

[spring-projects-issues]

Rod Johnson commented

Need to synch this up with JMX support for 1.2.

[spring-projects-issues]

Rod Johnson commented

I'm now thinking a properties based mechanism is most appropriate here. Similar to PropertyOverrideConfigurer, but the properties can change dynamically.

I'm not sure that reloading an entire definition file makes sense, especially now with support for database-based beans. The most obvious case would appear to be properties that can change at runtime and automatically be picked up.

Alternatively, simply managing this via JMX might be good too...

[spring-projects-issues]

alberto manjarrez commented

I agree on mostly support changes for properies only. That should satisfy most requirements. However I do not agree for this be only via JMX. Multiple apps won't have a JMX server. For me is a matter of changing the bean definitions, recycling share instances and creating prototype objects with new new property values.

[spring-projects-issues]

Justin Meyer commented

I agree that a properties based mechanism would be very useful. Although I would like the option of being able to reload an entire set of bean definitions, do a diff with the original definitions and then apply the changes that were made. This way someone could update the original source, file / database whatever and have the changes take affect. You could still restrict the permissible changes to bean properties, but you would also have the option of supporting more advanced updates in the future such as hot-swapping instances.

I also have a suggestion for the JMX approach. I agree that the WebLogic approach is not very elegant and can lead to a corrupt configuration file. Another option is to use a hierarchical configuration where updates are persisted to a new configuration file at the end of the hierarchy. This way you don't have to worry about merging the changes in with the original configuration which could have come from one or more XML files, property files, a database, etc. A naming convention could be used to pick up the new file / files the next time the application is started. Of course you may not want to write back to a file necessarily so a pluggable mechanism could be used for determining where and how to persist the changes.

[spring-projects-issues]

Jason Poley commented

Why does this seem to always be pushed back to a way off release? I think this feature is very important, and would really help spring. Is there any chance to move it up to a sooner 2.0 release?

[spring-projects-issues]

Juergen Hoeller commented

This is unfortunately non-trivial to implement within typical J2EE deployment units, in particular since other parts of an application may obtain Spring bean instances from an ApplicationContext and hold on to them. The broader solution for this is smaller deployment units which allow for individual hot redeployment. The most interesting solution is OSGi here, as already covered by the Spring OSGi project.

We'll revisit this issue for Spring 3.0, seeing whether there is anything to provide beyond OSGi here.

Juergen

[spring-projects-issues]

Jon Osborn commented

WL 9.2 reloads the context if you touch the spring jars. We can usually do just a (we build with maven) mvn clean install on an exploded deployment and the context reloads just fine. also a application stop/start works. (checkout the weblogic mojo at codehaus).

[spring-projects-issues]

Dennis Kieselhorst commented

I think stop/ start (redeploy) is not an option for a dynamic refresh ;-)

[spring-projects-issues]

Juergen Hoeller commented

This is not considered to be within the scope of the core Spring Framework project anymore. Dynamic refresh needs to happen at the deployment unit level - in other words, it is most natural to manage it in the hosting environment and not within the framework. OSGi and in particular SpringSource dm Server are the obvious technologies in that space.

Juergen

[spring-projects-issues]

Misagh Moayyed commented

Follow up on this discussion; there seems to be an interest in allowing the context to refresh based on properties that may dynamically change. This is something that I am currently dealing with today and have resorted to extensions for now that do this.

<util:properties id="casProperties" location="${cas.properties.filepath:/WEB-INF/cas.properties}"/>
<context:property-placeholder properties-ref="casProperties"/>

...where upon changes to cas.properties, I'd like the context to recognize those and re-adjust accordingly.

Is that something that can be done by the core of the Spring framework project? If so, could I create a separate JIRA to track the new feature?