Bug 192308

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.