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: | can no longer compile jsp pages | ||
---|---|---|---|
Product: | javaee | Reporter: | emiddio <emiddio> |
Component: | JSP | Assignee: | Anton Chechel <manowar> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | bhulse, dkonecny, jskrivanek, kRyszard, mmirilovic, pjiricka |
Priority: | P2 | ||
Version: | 7.0 | ||
Hardware: | PC | ||
OS: | Windows 7 x64 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
sample project
proposed patch project that still fails to compile jsp -- was doing lots of testing |
Description
emiddio
2010-11-22 23:46:49 UTC
Created attachment 103215 [details]
sample project
There seems to be something going on with jasper where it sometimes doesn't recognize libraries that are not marked for packaging in the war. I have two applications using the same libraries (though not necessarily the same tags). One compiles without issue, the other fails. If I change the failing application to package the library, then it compiles without error. The library I am using is for our security system. It consists of two jars, one which contains all the classes, the other just containing the tld file in the META-INF directory. The tld jar is always packaged with applications, the class jar is not since it is already installed in the domain/lib directory of the server. The thing I don't understand is why the first application compiles without error even though the class jar is not marked for packing in the war. So there seems to be some inconsistency in jasper's class resolution. This appears to be the same issue with the provided example. Changing the library settings to use JSF 2.0, it compiles fine if that library is marked for packaging, but fails if it isn't. Disabling pre-compilation and leaving JSF 2.0 unmarked (so that it isn't packaged) allows it to compile, deploy and execute without issue. I can reproduce this problem. Looks like this appeared after the upgrade of the bundled JSP compiler to the version from GlassFish 3.0.1 (jsp-impl-2.2.1). Looking at JspC sources, could we use the -classpath or -sysClasspath parameter of JspC to fix this? The -sysClasspath was introduced by this fix, i.e. relatively recently: http://java.net/projects/jsp/sources/svn/revision/1159 I can reproduce it as well. Investigating... thanks for looking at this guys. guess i need to select P2 priority to get things looked at initially. The problem lays in classpath what should be passed to org.netbeans.modules.web.project.ant.JspC during JSP compilation. If user includes JSF libary in the project then in the runtime I can see ${libs.jsf20.classpath} property and if I add it to classpath after ${libs.jsp-compilation.classpath} in build-impl.xml, it compiles JSP correctly. So I predict new glassfish-jspparser-3.0 behaves differently comparing to glassfish-jspparser-2.0 (which have been used in NB6.9) in the way of loading resources. So, David, my question is: do we have some property which contains all user included libraries in the project so I can add it to JSP compilation classpath? yesterday i created new similar bug -- i had not seen any activity on this in some time and thought was fixed in nb70beta2 http://netbeans.org/bugzilla/show_bug.cgi?id=196204 *** Bug 196204 has been marked as a duplicate of this bug. *** Awaiting reply from Kim-man Chung, owner of Glassfish JSP Parser. No response from Kim-man so far. Attaching proposed patch. Created attachment 106787 [details]
proposed patch
(In reply to comment #10) > Attaching proposed patch. Does this really help? When I was testing this my javac.classpath was empty (a Web Project) because JSF library was coming from application server (which is not included in javac.classpath). (In reply to comment #12) > Does this really help? When I was testing this my javac.classpath was empty (a > Web Project) because JSF library was coming from application server (which is > not included in javac.classpath). With the given at this bug project it compiles JSP for me only when I add JSF library to javac.classpath. I tried both glassfish-3.1-b41 and tomcat 7.0.6. What I mean is that patch itself is not fixing the issue - second necessary step is to add JSF library to project compilation classpath in order to make it compile JSP. An alternative solution would be to add directly ${libs.jsf20.classpath} to classpath instead of ${javac.classpath}. But I would feel reluctant to do that unless I know why I'm doing that. (In reply to comment #14) > What I mean is that patch itself is not fixing the issue - second necessary > step is to add JSF library to project compilation classpath in order to make it > compile JSP. I thought it's obvious when user uses JSF he adds the library. But I didn't know it's already in appserver. > An alternative solution would be to add directly ${libs.jsf20.classpath} to > classpath instead of ${javac.classpath}. But I would feel reluctant to do that > unless I know why I'm doing that. I agree, I don't like that solution either. I just wrote another mail to Kim-man and waiting for reply. fixed http://hg.netbeans.org/web-main/rev/fad1e8418125 integrated into trunk waiting for reviewer approval One thing I would recommend to test: create a project in NB 6.9.1 with sharable libraries and enable JSP compilation and then open it in 7.0 with your fix and double check that newly introduced library for sys classpath is available and everything compiles OK. fixed binaries http://hg.netbeans.org/web-main/rev/07c1c5ab95c8 will transplant changes to 7.0 branch (In reply to comment #17) > One thing I would recommend to test: create a project in NB 6.9.1 with sharable > libraries and enable JSP compilation and then open it in 7.0 with your fix and > double check that newly introduced library for sys classpath is available and > everything compiles OK. I have tested it with NB 6.9. changes have been reverted due to test failing http://hg.netbeans.org/web-main/rev/51dba5492e01 working on fixing tests locally Integrated into 'main-golden', will be available in build *201103240400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/fad1e8418125 User: Anton Chechel <manowar@netbeans.org> Log: issue #192308 has been fixed *** Bug 189734 has been marked as a duplicate of this bug. *** *** Bug 195586 has been marked as a duplicate of this bug. *** fixed with tests http://hg.netbeans.org/web-main/rev/bb8483e9247d Integrated into 'main-golden', will be available in build *201103300400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/bb8483e9247d User: Anton Chechel <manowar@netbeans.org> Log: issue #192308 has been fixed Verified in NetBeans IDE Dev (Build 201103300400) Java: 1.6.0_24; Java HotSpot(TM) Client VM 19.1-b02 System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb) Please, fix in NB 7.0. integrated into "release70" branch changesets: http://hg.netbeans.org/releases/rev/a75bb2e548be http://hg.netbeans.org/releases/rev/6ca63effb752 http://hg.netbeans.org/releases/rev/de904c3c46ac http://hg.netbeans.org/releases/rev/e2d2c095fd63 http://hg.netbeans.org/releases/rev/2bbbd6b677ca Added related additional fix for JspCSingle: http://hg.netbeans.org/releases/rev/276bcefbf96e From now on compilation of single JSP (F9 in editor) should work as well. Created attachment 107444 [details]
project that still fails to compile jsp -- was doing lots of testing
see prev entry and project -- found another case that fails (In reply to comment #30) > see prev entry and project -- found another case that fails Attached test case is not valid: if you want to compile individual template files you have to turn them into valid files. For example washington.jsp does not declare any taglib and therefore cannot be compiled. Add <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> and it will compile fine. If there are any other testcases please file them as new issues. Thanks. thanks, BTW -- index.jsp would not compile singly even when i got rid of the includes, which i tested before my last report and project attachment submission -- and would not compile singly again even after making the changes you said to do to the included jsp fragment files. discovered if i move the taglib directives -- ie, such as - <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> from inside the <html> block to the top of the page in index.jsp it would then compile singly. without the change -- project build would work and compile the jsp pages without errors, but F9/compile singly the jsp page would not work. again thanks (In reply to comment #32) > BTW -- index.jsp would not compile singly even when i got rid of the includes, > which i tested before my last report and project attachment submission -- really? index.jsp compiles fine for me always. regardless of whether template files contain taglib definition or not. and regardless of the placement of taglib definition in index.jsp (before or after <html>). I'm testing it on today's build (20110404). How could I reproduce it? a slight correction -- if i clean project, then try to compile singly the index.jsp i get an error -- to be posted later in this msg; my mistake - does not matter if tablib declaration is at top of file or nested under html. if i build project after clean -- with project configured to build jsp pages, all the pages get compiled -- if i then compile singly index.jsp the compilation succeeds. Product Version: NetBeans IDE Dev (Build 201103300400) Java: 1.6.0_23; Java HotSpot(TM) 64-Bit Server VM 19.0-b09 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb) Userdir: C:\Users\emiddio\.netbeans\dev clean, then compile singly : compile-single-jsp: init: deps-module-jar: deps-ear-jar: deps-jar: Created dir: C:\Sun\corejsf2-examples\ch07\tabbedpane\build\web\WEB-INF\classes Copying 14 files to C:\Sun\corejsf2-examples\ch07\tabbedpane\build\web library-inclusion-in-archive: library-inclusion-in-manifest: Created dir: C:\Sun\corejsf2-examples\ch07\tabbedpane\build\empty Compiling 2 source files to C:\Sun\corejsf2-examples\ch07\tabbedpane\build\web\WEB-INF\classes Copying 1 file to C:\Sun\corejsf2-examples\ch07\tabbedpane\build\web\WEB-INF\classes compile: Created dir: C:\Sun\corejsf2-examples\ch07\tabbedpane\build\generated\src org.apache.jasper.JasperException: file:C:/Sun/corejsf2-examples/ch07/tabbedpane/build/web/index.jsp(1,58) PWC6188: The absolute uri: http://java.sun.com/jsf/core cannot be resolved in either web.xml or the jar files deployed with this application org.apache.jasper.JasperException: PWC6188: The absolute uri: http://java.sun.com/jsf/core cannot be resolved in either web.xml or the jar files deployed with this application C:/Sun/corejsf2-examples/ch07/tabbedpane/build/web/index.jsp(1,58) C:\Sun\corejsf2-examples\ch07\tabbedpane\nbproject\build-impl.xml:624: The following error occurred while executing this line: C:\Sun\corejsf2-examples\ch07\tabbedpane\nbproject\build-impl.xml:602: Java returned: 1 BUILD FAILED (total time: 0 seconds) clean/build then compile singly: compile-single-jsp: init: deps-module-jar: deps-ear-jar: deps-jar: library-inclusion-in-archive: library-inclusion-in-manifest: compile: BUILD SUCCESSFUL (total time: 0 seconds) Thanks for the clarification emiddio. Unfortunately I cannot reproduce it. I will let Anton or somebody else to try it and reproduce it. The error in your latest comment is different as well - "PWC6188: The absolute uri: http://java.sun.com/jsf/core cannot be resolved". I cannot imagine why it should not work and be random as the same JspC Ant task is executed. Perhaps running Ant in verbose or debug mode and comparing when it passes and when it does not and what's the difference might shed some light on this. may i reopen this issue ? i can capture 2 outputs of verbose mode ant - both when fails, and when succeeds ,ie. when a clean/build is done first. Gary (In reply to comment #36) > may i reopen this issue ? > > i can capture 2 outputs of verbose mode ant - both when fails, and > when succeeds ,ie. when a clean/build is done first. Gary could you create a new issue please? This one already went through high resistance process to be integrated into 7.0 release. Thanks! Verified in Product Version: NetBeans IDE 7.0 RC2 (Build 201104050000) Java: 1.6.0_24; Java HotSpot(TM) Client VM 19.1-b02 System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb) Emiddio, what build do you use? Fix of this bug was integrated into RC2. On 7.0 RC1 (Build 201103280000) it still reproducible. |