Bug 192308 - can no longer compile jsp pages
can no longer compile jsp pages
Status: VERIFIED FIXED
Product: javaee
Classification: Unclassified
Component: JSP
7.0
PC Windows 7 x64
: P2 with 2 votes (vote)
: 7.0
Assigned To: Anton Chechel
issues@javaee
: 70_HR_FIX
: 189734 195586 196204 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-22 23:46 UTC by emiddio
Modified: 2011-04-06 12:24 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
sample project (18.49 KB, application/x-zip-compressed)
2010-11-22 23:47 UTC, emiddio
Details
proposed patch (1.65 KB, patch)
2011-03-07 15:30 UTC, Anton Chechel
Details | Diff
project that still fails to compile jsp -- was doing lots of testing (32.14 KB, application/octet-stream)
2011-04-03 16:43 UTC, emiddio
Details

Note You need to log in before you can comment on or make changes to this bug.
Description emiddio 2010-11-22 23:46:49 UTC
with project build compiling option "test compile all JSP files during builds"

get errors with nb691 for older projects;

attached project is from Core JSF book -

compiles with nb651; will not compile with nb691
Comment 1 emiddio 2010-11-22 23:47:39 UTC
Created attachment 103215 [details]
sample project
Comment 2 perrych2 2011-01-14 13:33:40 UTC
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.
Comment 3 Petr Jiricka 2011-01-17 15:48:37 UTC
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
Comment 4 Anton Chechel 2011-01-17 16:05:42 UTC
I can reproduce it as well. Investigating...
Comment 5 emiddio 2011-01-17 20:11:17 UTC
thanks for looking at this guys.

guess i need to select P2 priority to get things looked at initially.
Comment 6 Anton Chechel 2011-03-03 16:55:06 UTC
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?
Comment 7 emiddio 2011-03-03 19:50:31 UTC
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
Comment 8 Anton Chechel 2011-03-04 12:02:11 UTC
*** Bug 196204 has been marked as a duplicate of this bug. ***
Comment 9 Anton Chechel 2011-03-04 13:45:39 UTC
Awaiting reply from Kim-man Chung, owner of Glassfish JSP Parser.
Comment 10 Anton Chechel 2011-03-07 15:29:20 UTC
No response from Kim-man so far.
Attaching proposed patch.
Comment 11 Anton Chechel 2011-03-07 15:30:14 UTC
Created attachment 106787 [details]
proposed patch
Comment 12 David Konecny 2011-03-07 18:10:41 UTC
(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).
Comment 13 Anton Chechel 2011-03-08 14:34:39 UTC
(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.
Comment 14 David Konecny 2011-03-09 21:39:30 UTC
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.
Comment 15 Anton Chechel 2011-03-11 15:03:33 UTC
(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.
Comment 16 Anton Chechel 2011-03-18 14:05:02 UTC
fixed http://hg.netbeans.org/web-main/rev/fad1e8418125
integrated into trunk
waiting for reviewer approval
Comment 17 David Konecny 2011-03-20 20:32:51 UTC
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.
Comment 18 Anton Chechel 2011-03-21 11:07:09 UTC
fixed binaries
http://hg.netbeans.org/web-main/rev/07c1c5ab95c8

will transplant changes to 7.0 branch
Comment 19 Anton Chechel 2011-03-21 11:07:44 UTC
(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.
Comment 20 Anton Chechel 2011-03-23 17:06:54 UTC
changes have been reverted due to test failing
http://hg.netbeans.org/web-main/rev/51dba5492e01
working on fixing tests locally
Comment 21 Quality Engineering 2011-03-24 09:47:49 UTC
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
Comment 22 Anton Chechel 2011-03-28 11:54:29 UTC
*** Bug 189734 has been marked as a duplicate of this bug. ***
Comment 23 Anton Chechel 2011-03-28 13:02:13 UTC
*** Bug 195586 has been marked as a duplicate of this bug. ***
Comment 24 Anton Chechel 2011-03-29 17:39:57 UTC
fixed with tests
http://hg.netbeans.org/web-main/rev/bb8483e9247d
Comment 25 Quality Engineering 2011-03-30 08:41:45 UTC
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
Comment 26 Jiri Skrivanek 2011-03-30 11:25:43 UTC
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.
Comment 28 Anton Chechel 2011-03-31 15:20:41 UTC
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.
Comment 29 emiddio 2011-04-03 16:43:23 UTC
Created attachment 107444 [details]
project that still fails to compile jsp -- was doing lots of testing
Comment 30 emiddio 2011-04-03 16:44:04 UTC
see prev entry and project -- found another case that fails
Comment 31 David Konecny 2011-04-03 20:11:31 UTC
(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.
Comment 32 emiddio 2011-04-03 20:28:16 UTC
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
Comment 33 David Konecny 2011-04-03 21:30:07 UTC
(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?
Comment 34 emiddio 2011-04-04 00:33:24 UTC
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)
Comment 35 David Konecny 2011-04-04 00:50:50 UTC
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.
Comment 36 emiddio 2011-04-04 01:15:10 UTC
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
Comment 37 David Konecny 2011-04-04 01:26:59 UTC
(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!
Comment 38 Jiri Skrivanek 2011-04-05 09:10:38 UTC
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)
Comment 39 Anton Chechel 2011-04-06 12:24:50 UTC
Emiddio, what build do you use?
Fix of this bug was integrated into RC2.
On 7.0 RC1 (Build 201103280000) it still reproducible.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo