Hi Henning,
[can't set property if accessors defined in friendly superclass]
This is not an academic question, it is exactly the problem I've
written about yesterday with commons-dbcp. There is "public
SharedPoolDataSource" which extends "abstract
InstanceKeyDataSource". One cannot set properties defined in
InstanceKeyDataSource with PropertyUtils because of this problem.
Right, that's certainly not an academic question. I encountered the same problem recently when I wanted to have a common package-private superclass for some beans, but didn't want to have this superclass exposed in the public interface of that package as it is really just an implementation detail: At some point I may have to reimplement the whole package (ideally have the classes generated) in which case the superclass might vanish.
I'd be interested if the correct solution is to add a "public" toMy workaround was to set the class to public and document that it isn't
InstanceKeyDataSource or rewrite the MethodUtils::getAccessibleMethod().
really. Obviously I'd much prefer having getAccessibleMethod rewritten,
but am not quite sure how to do that correctly.
The requirement for a public class is a limitation of introspection in Java that BeanUtils inherits from java.beans.Introspector. The logic in getAccessibleMethod() took a long time to get to its current state (it includes workarounds for bugs on some JVMs), and I'm hesitant to mess with it without a *substantial* suite of test cases to verify we don't break anything. Unfortunately, I don't have time to work on such a suite at the moment :-(.
One workaround to exposing more public properties than you really want (which has also been discussed on this thread) is to use a BeanInfo class to describe your bean class. Using this technique, you can tell the introspector exactly which properties to expose (and even use different method names than the usual design pattern requirements, if you want). See the JavaBeans Specification for more information:
http://java.sun.com/products/javabeans/docs/
Thomas
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
