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.
build 201, dev I cannot compile a standard JSP file (created using template) This has been reproduced under WinNT and OS/2
Also, I have verified that \netbeans\lib\ext\servlet.jar is indeed in the path and it contains the correct files. I have noticed that while editing standard Class files, I can see javax.servlet.* but under JSP files I cannot.
I think I found the problem.. Looking into ide.log I noticed that whenever "java" is used, the entire CLASSPATH is passed after "java -cp" but when "javac" is used, only the project directories are placed after "javac -cp". As a result, many files which must be placed on the classpath are missing. Servlet.jar being one of them.
I have verified my hypothesis, forcing "servlet.jar" to be added after the default classpath statement fixes the problem. Netbeans stops complaining about "javax.servlet.*" and instead complains about "jasper" which is _also_ missing from the classpath. This looks like an easy fix. Could you please take care of it as soon as possible? :)
When JPDA is used, the shortened classpath is used as well. JAVA.EXE is indeed being used, but the classpath is wrong again.
*** Issue 12945 has been marked as a duplicate of this issue. ***
Assigning to CORE as this stretchs beyond a problem in WEB. Problem occurs in compiler/executor engines which (as far as I can tell) are the responsibility of CORE.
This problem is even worse than I had originally thought. See issue #12945.. For all of the other mentioned problems I know how to manually add statements to CLASSPATH, but for the Bean problem I have no idea what has to be modified as no output shows up in IDE.LOG. How does one find out what classpath is being used by the CUSTOMIZE BEAN feature?
Argh.. I give up.. I keep on getting mixed behavior. One second I get one error, another minute I get another. I would really appreciate it if someone else could reproduce this problem. Meanwhile I'm going to reinstall my copy of Netbeans. Issue #12945 is a big question mark. It might be related to this problem and then again it might not be. All _other_ issues I have mentioned are 100% reproducable so you can rely upon them.
Ok, this does it ;) I'm using Netbeans 3.2.1 under winNT 4.0 (fresh install) and this bug just showed up.. This is far worse than I had originally thought.. Picture this: 1) I have 4 mounted directories, one of which declares a class called "Object" 2) From another directory (not the one mounted with class Object) I try to compile a JSP file 3) The JSP file won't compile because "Object page = this;" is found in the servlet code (harded by the JSP compiler) and it fails to compile because it finds _MY_ version of Object which is declared within another (totally different) mounted directory. How screwed up is that? Umm, I'm going to mount this bug to a P1 because its effects are far reaching (touches almost all modules) and quite severe. If you feel this is inapproriate, feel free to lower its priority to back to P2. It would be nice to get feedback from you guys about this issue, seeing as I have gotten none since reporting this bug back in June.
Check out issue #8806.. It might be related. I didn't add the dependency to this issue, but you might consider doing so.
Your page does not compile because this is a problem with your page and your Java class, not with the IDE. Per Java language specification, your Object class will override the java.lang.Object class, and will be in the classpath before java.lang.Object. The workaround is 1) to give your classes better names, different than "Object" or 2) put your class into a package or 3) if you really want to have a class in the default package called "Object", you need to explicitly import java.lang.Object into your JSP, so it takes precedence over your Object: <%@page import="java.lang.Object" %>
This is a user error, not IDE bug.
You're not listening to what I said. My Object class is NOT within the same directory as my JSP file. In fact, it shouldn't be within the classpath of the compiler when I try to compile the JSP file, but it is; which is a bug. If I have two mounted directories: 1) \work1 2) \work2 where (1) contains my JSP file and (2) contains some definition of Object, compiling (1) should have nothing to do with compiling (2). They don't share a classpath.
The fact that all filesystems mounted in the IDE are included in the classpath (in the order in which they appear in the Filesystems) is actually by design. This is necessary for larger projects, which need to store files in multiple source hierarchies. Without this feature, it would not be possible to develop large projects in the IDE. It can be seen from the IDE log that all filesystems mounted in the IDE are used in the classpath.
I understand. Ok, so let me clarify: my original understanding was that each mounted directory represents a different project. How does one accomplish this sort of behavior in the current version? I tried playing with Projects before and they were a big mess (very inconvient to use). It's much easier to simply use the EXPLORER tab.
Currently the support for Projects in the IDE is limited. Many things are not possible to accomplish with the current designs, so new project infrastructure needs to be introduced to cope with them. For now, the design is that all filesystem together constitute the classpath of a single project. Given that, the behavior of JSP compilation behaves as designed.
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.