Can JMX support in Spring (1.2.1) allow me to "reload" beans?

[dkarr]

I'm going to be doing some prototyping of the jmx support in Spring (version 1.2.1 at this point), with an existing somewhat large Spring application.

The two things I want to show are:

* the ability to dynamically set properties of existing beans
* the ability to "reload" beans that reference properties that have changed

I think the former will be somewhat straightforward, but I'm wondering about the latter. If my Spring properties files (not the XML files) are stored outside of the ear, and I change some values, is there any way to cause the application context to be "reloaded" to reflect the new values, so that beans referencing those properties will get changed property values?

[Costin Leau]

It depends what level of reloading do you want. For example if want to modify the property of a bean, you should retrieve it, change the properties and you're done. This is independent of Spring, you just call the setter on the instance.
I'm basically suggesting the first approach. Reloading is a feature that has been discussed quite a number of times on the forum but it is not yet implemented since it is not so easy to achieve.
An application context contains the dependencies betweens the beans and adding but especially removing a bean causes the whole tree to be parsed again. the simples solution is usually the best one. moreover in this case it's more JMX like using the setter instead of a total reload.

[vvernon]

FWIW, this is exactly what JMX notifications were meant to handle, which is based on the Observer pattern (pub-sub), but lightweight.

If an interested party needs to know when a value changes, the MBean must send a notification when significant property change events occur and the interested party should register itself as a notification listener.

There is also the matter of persisting configuration changes once they have been tuned, say via a console, so they can be reused upon subsequent startups. This generally has be be handled by the development team (see WebLogic's config) so is more difficult.