Kommentare zu: Spring Properties Reloaded

Von: axel

axel — Thu, 01 Dec 2011 09:13:50 +0000

Good observation - the bean’s code will actually have to handle synchronization itself. That is, if you want your bean’s configuration properties to be changeable during operation, the new value has to be communicated from the thread observing the properties file to the bean instance doing the actual work. So you will have to use a volatile or synchronized keyword at some point.

Using the ReconfigurationAware interface, you can even do this for multiple properties at once, by first storing the new values in a temporary place and then copying the values in one synchronized block in the afterReconfiguration callback.

Von: ken

ken — Wed, 30 Nov 2011 03:54:13 +0000

Very interesting!

How do you handle threading and synchronization issue? Your update will most likely occur in a thread that is different from those reading the value. Unless the property’s backing field is volatile (for simple value) or Atomic (for complex values), the reading thread can potentially never see the new value, or see a completely different value than the one you are setting!?

Thanks.

Von: subavinodhini

subavinodhini — Thu, 04 Feb 2010 07:37:56 +0000

I have one properties file having the value
totalNumberOfRows=100
if the user changed the value from 100 to 200.It should work accordingly without restatring the server. For that i need to write the spring listener.Do i use the above code for my work.

Suggest me some simplest thing to complete this.

Von: Melih

Melih — Wed, 25 Feb 2009 10:18:56 +0000

Thanks, it is well designed and well coded, but it can be rewritten according to spring 2.5 spec.
If I managed that I will let you know it…

Von: axel

axel — Thu, 08 Jan 2009 21:39:42 +0000

michael: true, but that only works if the injected beans are used through some kind of interface - it will not work for injecting an integer, which is afterwards used for all kinds of computation. A good example is dimension of cache sizes -the cache implementation wouldn’t want to go through a service interface every time it needs to determine whether the cache it full, and it will probably use the cache size for allocating resources (e.g. internal arrays) up front. So reacting to a changed configuration will involve some code implemented in the setter (push style / callback style).

Von: Michel Schudel

Michel Schudel — Thu, 08 Jan 2009 11:08:28 +0000

More complex cases like maps, list etc. would be simpler if the reloadable implementation is done with proxies instead of an observer. For example, if a “#{…}” is found anywhere in the application context, you can inject a proxy there that retrieves the current property value from the FactoryBean (or from a ReloadableMessageSource, for all I care).

Von: sridharan

sridharan — Thu, 06 Nov 2008 11:07:57 +0000

We have property file entries for maxlength and min length.

In many cases these keys are not used in the application.

Is there any way of finding out these keys,.

Von: axel

axel — Mon, 14 Jan 2008 23:37:40 +0000

True, the functionality is currently limited: It works well as long as you just have string properties of named singleton beans containing a placeholder. For more complex properties, more complex update code or an even more core-level solution would be required. Handling map and list should be feasible, I think, but the impact of value conversion isn’t quite clear to me.

This stuff requires a bit more code reading and thinking.

I recently noticed that properties of inner beans (a bean element contained in a property element) are not reloadable either, because Spring (at least Spring 2) ignores the name of an inner singleton bean. That’s always fixable (just move the bean outside and use a ref), but unfortunate.

Von: David

David — Thu, 20 Dec 2007 23:41:54 +0000

I made a mistake in my last post of including tags and the site has stripped them. Sorry it was meant to read

Hi, has anyone had difficulties when reloading map or list properties?

It seems that the latest version of spring reloaded cant handle this. The two scenarios are quite different.

1. map. it looks like the reloader is trying to assign one of the individual property values to the actual map property.

2. list. no exceptions are thrown here but the list property is re populated with only the property value that was changed. For example if you started with a list of 12 items, after the reload you only have one item

Von: David

David — Thu, 20 Dec 2007 23:38:45 +0000

Hi, has anyone had difficulties when reloading or properties?

It seems that the latest version of spring reloaded cant handle this. The two scenarios are quite different.

1. it looks like the reloader is trying to assign one of the individual property values to the actual map property.

2. no exceptions are thrown here but the list property is re populated with only the property value that was changed. For example if you started with a list of 12 items, after the reload you only have one item

Would be greatful if anyone could help me out here