|
How can I find out if there is any activity or interest in this issue? What else can I do to get the patch applied?
David, I know it can be frustrating to not get any feedback upfront. If I were you, I'd send an email to the dev mailing list asking for feedback on the validity of the approach, and inquire whether somebody can take ownership of this issue. If, in the meantime, you could try to run the CTF suite and see whether everything still runs fine, you'd definitely decreease somebody else's workload.
CTF test suite run output file (CTF run without patch)
I've run the CTF suite against CVS HEAD with and without the patch, and attached the output of the CTF suite. (ctfrun_out.txt is output without patch, ctfrun_out2.txt is output with patch). The patch doesn't break any CTF tests.
Just following up with regards to your email to the dev mailing list. I really don't believe that the listeners should be serialized at all, but in order not to break that behaviour, making this configurable per castor.properties sounds about right to me.
Attached a patch that permits configuration of this feature (on/off) via the standard properties file with the default setting being equivalent to pre-patch behaviour.
Totally disagree.
1) PropertyChangeListener interface is not serializable. Either move to PropertyChangeSupport in all generated objects, or make darn sure we never serialize by marking it transient. And by all means, break current and historical behavior.
Good point: using PropertyChangeSupport would permit runtime choice of listeners participating in serialization.
Alright, not knowing a lot about PropertyChangeListeners et alias, what does this translate to ? It looks like the configuration mechanism via castor.properties is not required.
Correct - no configuration mechanism, as it shouldn't exist.
Basically, the purpose of using PropertyChangeSupport is twofold: Add support for proxied listeners, and properly support serialization. If you don't use the PropertyChangeSupport methods, you have to code it all yourself; moreover, because you've got a raw list, you then also have to code your own manual serialization/deserialiation methods - something which this just can't do. PropertyChangeSupport implements all the required methods for serializing and deserializing safely; it also implements all the helper methods needed, in a way that supports proxyied listeners.. Please move to a PCS-based implementation to eliminate this and other problems, as that's the intended implementation of PropertyChangeListener support in beans objects. As for what this is for? I have no idea. I never use sourcegen. PropertyChangeSupport does indeed appear to be the least intrusive approach, and does follow the serialization behaviour as intended by the Java standard. This patch causes the source generator to generate JavaBeans with java.beans.PropertyChangeSupport instead of Vector.
Small change to submitted patch to retain existing signature of the removePropertyChangeListner method.
|
|||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
SourceGenerator: PropertyChangeListeners for bound properties should not be serialized
It's not clear how to make JUnit check for a transient keyword in the test case.