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.
I have defined a class called Constants in my project that I use to keep identifiers in the JSP consistent across all pages and then in the servlets used to process them. The problem is that when I import the class constants (package org.myproject.util.Constants) into the JSP page, then attempt to use it to get autocomplete, NetBeans 3.5rc2 ALWAYS insists on completing the values from org.apache.xalan.templates.Constants. I have removed ALL of the parser database entries using the manager EXCEPT the JDK14 listing and my own that I generated from my project, and I have also removed ALL of the javadoc entries too, and shutdown NetBeans and restarted it multiple times to no avail. NetBeans seems insistant on auto completing from this package, and I have no idea why. This problem might be more universal, but I happened to notice it with this one class.
This bug is now popping up in my normal Java code completion (while editing servlets). The only things I have in my code completion DB is the jdk14 and servlet23jsp12 completions that shipped with NB as well as a parser DB for my source code for this project. But I am still getting forced autocomplete options from org.apache.xalan, this is strange!
Ok now the bug has stopped popping up in my servlet code completion but still persists in my JSP code completion... I wish I could be more helpful, this seems random....
Riyad, I don't see how this can be qualified as P1. I think you know guidelines well. I will evaluate it but from your decsription it doesn't sound like critical bug for release.
Radim, I agree P1 would be too extreme, but I'm actively protesting the release guidelines. For example, this bug makes autocomplete within JSP pages not work, while others may see this as a P3/P4 because its a simple fix or because it doesn't cause a core dump, I see it as a P1/P2 from a user perspective, because the feature doesn't work. As a user, that is my only concern, if features work or not. After talking through the release guideline issue for weeks now I think we are actually getting somewhere, and in the process don't want to cause undue work for you. Please set this bug to whatever priority you feel is appropriate. As long as it gets fixed. Best, -Riyad
I've read part of thread on nbdiscuss ;-) No doubt that priority cannot be set according to fix complexity. I will check what is wrong
Thank Radim, I appreciate it.
I am trying to evaluate this. When the code completion for class named Xyz is request the IDE needs to find appropriate package - it will search in the same package or using list of imported class/packages or will try to use the first class found in database with the same name. In your case it is the last possibility because the page is not analyzed as a whole. It will work if you write fully quallified name (of course you don't want to do this). So you can be sure that we are aware of this bug and we will address it later. OTOH it is not a bug that it offers Constants from o.a.x.t package - look into $JAVA_HOME/jre/lib/rt.jar - it is here.
I am attempting to reopen this, as I am having similar problems, and it's better than opening a new bug. Using standard 1.4.2 JDK, same NB release, and including minimal JAR's for supporting Struts, I am importing only: <%@ page import=" com.tekelec.beans.*, com.tekelec.oid.*, javax.naming.directory.*, javax.naming.NamingEnumeration, org.apache.commons.logging.Log, org.apache.commons.logging.LogFactory, java.util.ArrayList" %> And, I get the incorrect completion for the "Attribute" class, within the javax.naming package. Instead of the completion for javax.naming.Attributes, I receive the completion for java.util.jar.Attributes. From a user standpoint, this is a huge issue, as the subtleties of the code completion are easily overlooked and incorrect methods may be invoked, confusion is induced, and work is halted. Using the same imports, I am also getting a completion window saying "String" is in "org.apache.xpath.operations", instead of the expected "java.lang.String"
*** Issue 41652 has been marked as a duplicate of this issue. ***
tiresome problem
Fixed in the trunk.
V
I'm reopening this for 50cat. It seems to be a problem in 10/13/05 build for 5.0. A perfect example is: - Create simple web page - Add log4j as a library to the webapp - Add "org.apache.log4j.*" to the import list This gives correct constructor: Logger logger = org.apache.log4j.Logger.[_] This gives incorrect: Logger logger = Logger.[_]
Marek, can you look at this regression?
fixed Checking in java/editor/src/org/netbeans/modules/editor/java/JMIUtils.java; /cvs/java/editor/src/org/netbeans/modules/editor/java/JMIUtils.java,v <-- JMIUtils.java new revision: 1.40; previous revision: 1.39 done Checking in java/editor/src/org/netbeans/modules/editor/java/NbJavaJMISyntaxSupport.java; /cvs/java/editor/src/org/netbeans/modules/editor/java/NbJavaJMISyntaxSupport.java,v <-- NbJavaJMISyntaxSupport.java new revision: 1.14; previous revision: 1.13 done Checking in java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ResourceClassImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ResourceClassImpl.java,v <-- ResourceClassImpl.java new revision: 1.11; previous revision: 1.10 done Checking in java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ResourceImpl.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/jmiimpl/javamodel/ResourceImpl.java,v <-- ResourceImpl.java new revision: 1.109; previous revision: 1.108 done Checking in web/jspsyntax/src/org/netbeans/modules/web/core/syntax/JspJavaSyntaxSupport.java; /cvs/web/jspsyntax/src/org/netbeans/modules/web/core/syntax/JspJavaSyntaxSupport.java,v <-- JspJavaSyntaxSupport.java new revision: 1.26; previous revision: 1.25 done
Pressing CTRL+Space in 'Logger logger = Logger.|' statement shows code completion for org.apache.log4j.Logger class now. Verified in NetBeans 5.0 FCS build #200601251500.