This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The Generate BeanInfo should use the super-class bean info as it`s default values, and only add the appropriate new values. There should also be buttons to make all parent properties non-accessible or expert, as well as a button to do the same thing for events. Even better, a multi-selection should allow the button to work on just the selected items and make them inherit, be expert or normal or hidden.
Priority is changed to P4 (normal).
Now it is possible to use superclass (merged by introspection on super class)
Resolved for 3.3.x or earlier, no new info since then -> closing.
[I am not sure whether the following is exactly what was previously resolved in this issue. It is therefore also presented in nbusers mailing list. Please advise on whether this should become a new issue rather than a reopening] I wish to specify the BeanInfo settings for a property in a base class and have that setting automatically appear in the BeanInfo for all subclasses (as generated by the BeanInfo editor). That is, I with the BeanInfo editor BeanInfo settings to be "inherited" in accordance with the class hierarchy. However I get the following behaviour (simplified example): * class Root has a property "thing". * i go to the bean node in Root and use the BeanInfo editor to choose "include =false" for property "thing"; "thing" is correctly excluded from the generated Root_BeanInfo. * class Subclass extends Root. * i go to the bean node of Subclass and use the BeanInfo editor and find that property "thing" appears and is _included_; I must therefore again choose "include = false" (and so on with frustration through the entire hierarchy). * choosing "use superclass" at the top level bean editor node seems to have no influence; I would have expected it to result in the BeanInfo editor inheriting the property inclusion settings from the Root class (and down). Indeed I am yet to establish _any_ influence at all of the "use superclass" switch. This is a very important and common task when working with BeanInfo, surely someone else must have noticed the tedium of editing settings for the same property throughout an entire hierarchy ! Maybe I am missing something very simple, I cannot imagine the feature I am observing is intended, and it is too annoying to be overlooked. darren@webel.com.au
Well: Should probably be another enhancemen not this one reopened. Anyway. I see what you mean but this will probably end as wontix because the beanInfoEditor would have to analyse the superclassBeanInfo instead the superclass itself (current behavior) this is unimlementable using the source analysis. (User coud write pretty strange code into the superclasse's bean info). Compiling and executing the beaninfo is not an option.
I think it is doable. Once "Use Superclass" is checked, the BeanInfo Editor should present only those properties and methods that are "new" in given bean class - the rest are "inherited" from BeanInfo of the superclass (getAdditionalBeanInfo method is generated returning superclass BeanInfo). This is IMHO the behavior that makes sense and that is missing - the BeanInfo Editor currently does not exclude the superclass properties/methods. To get the list of the "new" properties/methods/etc (introduced in given subclass), the BeanInfo Editor can simply compare the sets taken from "raw" introspection of the bean class and of its superclass (using the Introspector.IGNORE_ALL_BEANINFO which does just the class introspection and does not instantiate user BeanInfo). So you don't need to analyze superclass BeanInfo at all and this can work. I'm attaching a simple sample of beans for experimenting.
Created attachment 13520 [details] bean and BeanInfo samples
Not that I would fix it. But if someone does please 1) do not use reflection, use srcmodel or whatever API will be available at the time 2) Maybe consider adding another option. The Use Superclass BeanInfo adds implementation of getAdditionalBeanInfo() into the generated BeanInfo. Having one option used for two purposes would be a mess.