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.
See more info here: http://bt2ws.central.sun.com/CrPrint?id=6323693
nice to have but not critical for 5.0
What is the actual problem that the user will see? If there is none, then this should be a TASK, not a DEFECT.
This issue is umbrella issue for problems that were reported by Findbugs tool. We can not easy determine particular bugs that can be seen by user despite of I think that this is still issue with low priority. BTW, our team agreed that we will use these tools for improving quality of our code.
I agree with all you say. My point is that DEFECT should be used for user visible problems. Since this does not indicate any user visible issues, it should be a TASK.
The correct definition of TASK is: Task is an activity to be done on behalf or in support of a feature or enhancement. Tasks do not typically require direct changes to the code base. I'm still thinking that invisible issues are defect with lower priority but feel free to change to TASK. It would be nice and useful resolve this after NetBeans 5.0 will be done, simply clean up code before implementing new features.
Partial fix. Checking in nodes/JBManagerNode.java; /cvs/serverplugins/jboss4/src/org/netbeans/modules/j2ee/jboss4/nodes/JBManagerNode.java,v <-- JBManagerNode.java new revision: 1.10; previous revision: 1.9 done Checking in ide/ui/JBPluginUtils.java; /cvs/serverplugins/jboss4/src/org/netbeans/modules/j2ee/jboss4/ide/ui/JBPluginUtils.java,v <-- JBPluginUtils.java new revision: 1.7; previous revision: 1.6 done Checking in ide/ui/AddServerPropertiesVisualPanel.java; /cvs/serverplugins/jboss4/src/org/netbeans/modules/j2ee/jboss4/ide/ui/AddServerPropertiesVisualPanel.java,v <-- AddServerPropertiesVisualPanel.java new revision: 1.10; previous revision: 1.9 done Checking in ide/ui/AddServerPropertiesPanel.java; /cvs/serverplugins/jboss4/src/org/netbeans/modules/j2ee/jboss4/ide/ui/AddServerPropertiesPanel.java,v <-- AddServerPropertiesPanel.java new revision: 1.6; previous revision: 1.5 done Checking in ide/JBStartServer.java; /cvs/serverplugins/jboss4/src/org/netbeans/modules/j2ee/jboss4/ide/JBStartServer.java,v <-- JBStartServer.java new revision: 1.31; previous revision: 1.30 done Checking in ide/JBLogWriter.java; /cvs/serverplugins/jboss4/src/org/netbeans/modules/j2ee/jboss4/ide/JBLogWriter.java,v <-- JBLogWriter.java new revision: 1.4; previous revision: 1.3 done Checking in JBDeployer.java; /cvs/serverplugins/jboss4/src/org/netbeans/modules/j2ee/jboss4/JBDeployer.java,v <-- JBDeployer.java new revision: 1.12; previous revision: 1.11 done Checking in JBDeploymentFactory.java; /cvs/serverplugins/jboss4/src/org/netbeans/modules/j2ee/jboss4/JBDeploymentFactory.java,v <-- JBDeploymentFactory.java new revision: 1.10; previous revision: 1.9 done Checking in config/WarDeploymentConfiguration.java; /cvs/serverplugins/jboss4/src/org/netbeans/modules/j2ee/jboss4/config/WarDeploymentConfiguration.java,v <-- WarDeploymentConfiguration.java new revision: 1.3; previous revision: 1.2 done
WONTFIXes: -Inconsistent synchronization WarDeploymentConfiguration.jbossWeb: Cannot occur in the real world. jboss-web.xml cannot be modified in the same time as the context value in the project's properties. -J2eePlatformImplImpl.getLibraries(): may expose internal representation...: The libraries are only read. -PathModel defines non-transient non-serializable instance field...: Caused by the fact that PathModel extends AbstractListModel which implements Serializable. PathModel is never serialized, thus there is no need to mark its fields as transient or serializable -Circular dependencies in the 'Add server' wizard classes: It is by design, it could be probably redesigned if it was really needed. -JBManagerNode and JBTargetNode inherit equals and uses hashCode(): Invalid. These classes inherit Node.equals() which uses '==' operator unless the compared object is FilterNode instance. In such case it delegates to FilterNode.equals(). And FilterNode also overrides hashCode(). Both cases guarantee that equal objects have the same hashCode() value.
Libore, can you write how many reported bugs did you fix? The percentage of the real issue can be useful for using similar tools in future. Thanks Petr
I don't remember the exact numbers. I think there was about 20 or 25 bugs found. Now there is 7 bugs which I described (some of them are duplicates, thus they are described at one paragraph).
Verified