BeanWrapper and PropertyChangeListener support

[hed]

hello

It's a quite typical web trier problem, but I've choosen this forum, because it touches more common things, e.g. binding.
I'm trying to build multipage, session form with list of items, where each of item can be edit by user. I need to receive an information about changed rows only, so first thought was to use PropertyChangeListeners.
I've found in docs following sentence:

Also, the BeanWrapper offers support for nested properties, enabling the setting of properties on sub-properties to an unlimited depth. Then, the BeanWrapper support the ability to add standard JavaBeans PropertyChangeListeners and VetoableChangeListeners, without the need for supporting code in the target class

Great! but...
acctually, BeanWrapperImpl has no support in this area. It is trivial to implement by changing existing code, but not by overriding this class - some method are private (like getNestedBeanWrapper), a lot of other objects create BeanWrapperImpl directly (e.g BindException). It seems that I have to do many changes in packages .validation and .beans to provide this simply functionality.

Is there any other way ? Maybe propertychangelistener support will be added in new releases ?

[Rod Johnson]

We actually did have support for property change listeners in the past, but we removed it because no one (including the Spring team) appeared to be using it, in accordance with our philosophy of driving the feature set by real use cases.

I'll update the documentation to reflect this. Where precisely in the documentation did you find this reference?

[hed]

-> 4.3. Bean manipulation and the BeanWrapper (the second paragraph)

But I'm not really sure that creating wrappers directly is a good idea. If there was a simple factory, it would be no problems to implement own, more sophisticated wrapper. At this moment there is no possibility to replace default implementation.

[mjastak]

I REALLY needed a support for PropertyChangeListeners and VetoableChangeListeners in last two projects developed by my company, I suppose it will be needed in the future too - is there any chance to bring it back? or at least make a BeanWrapper somehow modular and extendable to allow us to do it ourselves?

[Dave Syer]

What is your use case? Can you use AOP (might be cleaner anyway)?

[mjastak]

two cases:

1) spring 1.2.8 based web application - I have to write some kind of audit logs for data edited by user on User Interface, who has changed specified properties of some beans, and remember old and new value for each property - everything is stored into DB then

2) spring 2.0.2 and webflow 1.0.1 based web application - similar as above, I have to be able to check which properties of a beans has been changed on user interface, and write into DB some information driven by changed properties names (probably full path within some base object)

about using AOP - not sure about it - it is possible that I'll encounter strong opposition from customers for which we are writing this code,

[Dave Syer]

I guess the normal approach would be to use database triggers. With Spring 1.2.8 it will be difficult to enhance your domain objects with Spring AOP, since they are not typically Spring beans, and I guess even with 2.0.2 it might lead you to AspectJ (which I guess is what your customers might care about - they shouldn't care about Spring AOP). Or you are using Hibernate you can use a Hibernate entitity interceptor.

[mjastak]

in fact I was considering this solution, but the problem is that I have to write something like this when property P has changed - "User [user description] has changed [property description] for [bean owning property description] from [old value] to [new value]", where message which should be written depends on two things - bean owning property and property path within this bean, users descriptions are taken from external web service - as you see it is a bit complicated, and I believe we shouldn't move any application logic this kind to database layer, or even hibernate - in fact application logic shouldn't even know there is a hibernate as a persistance layer