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.
Summary: | Property evaluation doesn't take visibility into account | ||
---|---|---|---|
Product: | java | Reporter: | _ deva <deva> |
Component: | Beans | Assignee: | misterm <misterm> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | hmichel, jkovalsky, jpokorsky, misterm |
Priority: | P3 | Keywords: | NETFIX |
Version: | 4.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Tentative fix
Sample bean |
Description
_ deva
2005-10-11 21:20:29 UTC
Milestone is obsolete, please reevaluate It's broken for non-public classes as well, i.e., it finds properties for these cases. Raising priority for P3 (part of feature does not work). It is quite deceiving for the developer since any bean-based framework would claim properties don't exist, s/he thinks they do and the IDE seems to agree with them. The IDE makes such occurences quite common since when use a class that doesn't exist, the hint it provides creates a non-public class. I would like to fix this issue as part of NetFIX: http://wiki.netbeans.org/NetFIX Jan Pokorsky is willing to review and integrate the fix. Michael, please attach the patch. Thanks! After reading the spec thoroughly, the visibility requirement is specified only for properties, events and methods. The class doesn't need to be public, but then its features are only accessible to classes in the same package, which is deceiving. Therefore, I will fix it according to the spec - take visibility into account for property, events and methods - and file a separate issue to improve visual feedback for the non-public class use case. Created attachment 78674 [details]
Tentative fix
Patched. When PatternAnalyzer does not use deepIntrospection mode, it calls ElementFilter.methodsIn, which returns all methods, which is not consistent with its call to BeanUtils.methodsIn, which only returns public methods. This explains why BeanInfo editor works correctly but Navigator view is broken, for instance. Created attachment 78676 [details]
Sample bean
I've attached a sample bean to make the issue easier to understand. Before the patch: If you open it in the editor and choose Bean Patterns in Navigator, you will see a property and an event, which is wrong (methods have package-visibility). If you try to create a BeanInfo for the bean, it won't list any properties or events, which is correct. After the patch: Bean Patterns and BeanInfo editor behaviour is now consistent. Please let me know if you have more questions. The non-public class use case will be handled here: http://www.netbeans.org/issues/show_bug.cgi?id=160937 The patch is fine. Thank you. Integrated as http://hg.netbeans.org/jet-main/rev/c3acc9c00be2. You are right that Navigator's Bean Patterns and BeanInfo editor are consistent in this way but remember that the navigator, as it is implemented now, computes patterns just from editing file. It does not introspect super classes and it does not look for existing BeanInfos. Integrated into 'main-golden', will be available in build *200903250219* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/c3acc9c00be2 User: Jan Pokorsky <jpokorsky@netbeans.org> Log: #66529: collect only public property accessors v. 200903250219 The status whiteboard "65fixes4-candidate" has been removed. At this time our proactive patches for the NetBeans 6.5.x IDE have concluded. If you own a Sun service plan contract for NetBeans, you may wish to contact Sun Service http://www.sun.com/contact/support.jsp to request a fix via the product defect escalation process. For more information on purchasing a Sun service plan contract for NetBeans, refer to the service plan item "Sun Software Service Plans (S3P) for Developers" in the Sun Service table found on our NetBeans Support Resources page http://www.netbeans.org/kb/support.html |