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.
NB 5.5 RC2 Build 20061016 JDK 1.5 ========================= Step 1. Create zzz.someclass.java which has a public variable String test = "test"; Step 2. Create a simple jspx z.jspx containing these <use:bean id="hello" class="zzz.someclass"/> <jsp:body> <jsp:expression>hello.var</jsp:expression> </jsp:body> Step 3. Modify zzz.someclass.java by removing variable test, to ensure compilation error of z.jspx. Step 4. [F9] to recompile z.jspx without modifying it. Compiled with no error even though variable test is not found. Step 5. Make minor modification to z.jspx, like introducing a new line at end of file. [F9] again but this time z.jspx compiles with error as expected.
Step 2 should have been: Create a simple jspx z.jspx containing these <use:bean id="hello" class="zzz.someclass"/> <jsp:body> <jsp:expression>hello.test</jsp:expression> </jsp:body> Compiled without error.
Yes, this is known behavior. The jsp compiler use only the java classes. It doesn't check, whether the source of java file was changed. The jsp compiler only checks, whether the source of jsp was changed. Probably the fix can be done easily, just the jsp compilation should depend on the java source compilation. On the other hand, there will be performance problem. because before the jsp compilation will be done the compilation of all java sources.
I thought I had made a nb issue-zilla entry under a previous version of nb and I was quite sure it had been fixed. Anyway, under project properties, it would help to provide such a build option - JSP Compiler: check source changes That would provide for people with less capable machines to allow switching source validation/compilation off during jsp compilation. After all this is an IDE, not a production jee server. Now that I am aware of the issue, I should tire myself a lil' more by pointing mouse at project node and right clicking to build project before pressing
moving opened issues from TM <= 6.1 to TM=Dev
The IDE already compiles the java sources prior to jsp compiling. I'm not sure that's relevant. The real issue is that the jasper JSP compiler (org.apache.jasper.JspC) only recompiles a jsp (or jspx) if the jsp source has been modified since it last compiled the jsp. I can't figure out how to force jsp compilation via the JspC api. I tried setCompile(true), but it does not have the intended effect. If the JspC api offered a way to obtain the file location (or at least the class name) of the generated servlet, I could delete the existing generated servlet before recompiling. That would effectively force jsp recompilation. However, the JspC api does not seem to offer this information. The JspC api does offer a setClassName method. I suppose I could call this when compiling a jsp so that I would have control over the generated servlet's class name. That way, I could go ahead and delete the file before jsp recompilation. However, I'm not sure it's a good idea to mess with the generated servlet's class name, even if I do attempt to impersonate the default name. All this leaves me wondering: under the circumstances, is it so necessary to force recompilation? Marking incomplete for ideas/input.
ppisl, pjiricka, jayashri, please advise when you get a chance. Thanks.
If the bug is still reproducible it shouldn't be marked as incomplete, because there all informations to reproduce it. Is it still reproducible? Regarding the solution, shouldn't be enough to just call recompiling java classes before compiling jsp files?
I agree it's not a good idea to mess with the class name. Petr P, the solution you propose does not work, see Matt's comment above. My opinion is, let's not fix it. Yes it is a valid bug, but we don't get too many complaints about it. It is the same kind of behavior that you get when compiling Java classes with Ant without using <depend>, so let's close as LATER.
Closing as LATER. We can reopen it if more community demand arises.
NetBeans.org Migration: changing resolution from LATER to WONTFIX