Community
Participate
Working Groups
I'm using wtp-1.0M9.zip. When using Tomcat Project from Sysdeo (not dynamic web project) JSP validation doesn't see variables defined in another included JSP file. Below is example of it, compiler underlines 'variable1="test2";' saying "variable1 cannot be resolved". ****test2.jsp**** <%@ page import="java.sql.*" contentType="text/html; charset=ISO-8859-2"%> <!doctype html public "-//w3c//dtd html 3.2//en"> <% String variable1 = "test"; %> ****test1.jsp**** <%@ page import="java.sql.*" contentType="text/html; charset=ISO-8859-2"%> <!doctype html public "-//w3c//dtd html 3.2//en"> <%@ include file="/test2.jsp" %> <% variable1="test2"; %>
I verified this bug using a Dynamic Web project in just released WTP 1.0. I don't think Sysdeo plugin has anything to do with it.
Is test2.jsp in the WebContent folder itself (and not outside of it or buried within a folder under WebContent)?
Hmm... This is getting more weird. I can no longer reproduce it in a Dynamic Web project whether the fragment file is in the same folder or in a subfolder. I think this has something to do with somewhat inconsistent validation behavior on "save" (I do have "Run validation when you save changes" preference checked at default level but it doesn't seem to always propagate to projects). But this is an entirely separate problem. Now, testing it in a non-web project (e.g. a Java project or a Sysdeo tomcat project), it seems the problem is with fragment files included using an absolute path (e.g. /test2.jsp). This makes sense since the validator doesn't know where the webapp root is so it can't find the file. Creating a WebContent directory and putting everything under it doesn't seem to make any difference. Unfortunately, the validator does not ever complain that the included file is not found (is it a different bug?) which makes it more difficult to find the real error. What's more interesting, the auto-complete feature seems to find the TLD definitions from my included file (I have no idea how it figures that out). So, to summarize, what I think this boils down to is the ability to specify the webapp root directory. It would be nice to have that for Dynamic Web Project as well so that projects that have existed for years don't have to change their directory structure. Alternatively, it can try to figure out the webapp root based on the location of WEB-INF directory.
I can confirm too, that this bug still exists in 1.0 You can change definition of webapp root directory (in Dynamic Web Project) in project_folder\.settings\.component, hovewer validator seems not to use it.
Hi, I also have the same problem with wtp-all-in-one-sdk-1.0. Is it possible to temporarily turn off JSP validation? Best regards, Ivan
Mass transfer from pa to dw. Needs more triage.
This problem is not fix and can be repreduced very easily using 1.0.1. It is a critical bug for us as it renders JSP editor not usable for our portlet development support (oss portals come with layer and layers of inclusions for variables and taglibs). Can we review this again please. I have included a simple case that reproduces it. Create three files header.jsp body1.jsp and body.jsp in WebContent. body2.jsp cannot resolved variables. 1. header.jsp - declares a headerDate variable (compiles fine) Code: <!-- header.jsp --> <%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%> <% java.util.Date headerDate = null; %> 2. body1.jsp - does nothing, just includes header.jsp (compiles fine) Code: <!-- body1.jsp --> <%@ include file = "header.jsp" %> 3. body2.jsp - includes body1.jsp and attempts to use the headerDate variable, but Lomboz shows "headerDate cannot be resolved" error. Code: <!-- body2.jsp --> <%@ include file = "body1.jsp" %> <% java.util.Date bodyDate = headerDate; %>
Naci, I'm sure you meant "major" (major loss of function) instead of "critical" (crashes, loss of data). Also, I think as JST project lead you have every right to change the priority, say to '2', if that's what you intended to do.
Added to the 1.5 hot list. Setting priority to P2 and target to 1.5 M6.
yeap major no critical. Also, here is some other useful info about the problem. Stepping through the debugger, it happens that this not a nested includes problem but rather a scanner/parser problem. The problem surfaces when you add the include directive as the only line in the file no spaces etc. after (body1.jsp). Addinf a few blank lines and problem goes way. Howeve, this workaround make me nervous as we see problems with taglibs in nested includes, which we have not been able cleanly state but does not dissappers with the blank lines (but the variables problem does). As you can imagine, it is not fun to step through a scanner in the debugger so could not track it further. :-(
Update all 1.5 hot bugs to use the new hot bug process.
I've tested Naci's hypothesis that it has to do with line feeds after the include but found that it made no difference in problems manifesting on 1.0.x or 1.5rc2. It happens regardless of line feeds in 1.0 and never in 1.5. The variable in question is defined in a scriptlet file, so the custom tag content model can be ruled out as it ignores scriptlets. I'm ruling out the parser as a cause of this bug since it hasn't changed since before 1.0 and I'm seeing differing problems reported between 1.0.2 and 1.5rc2. Tag libraries being recognized in the root JSP when they're declared in a second-level deep included fragment shows that the parser is reporting all of the regions properly (plus the variables aren't declared using custom tags). That just leaves the translator itself. Marx, Naci, Alexey, could one (or all) of you attach minimal *projects* reproducing the error you're seeing? I've added a TestModelIncludes test suite to the org.eclipse.jst.jsp.core.tests 1.5 branch encapsulating Naci's scenario from comment 7 as best I could, but lacking the exact project file layout any of you are using, I can't be sure I've got it all laid out properly.
Moving to 'remind' as we are waiting for help to be able to reproduce.
I've tested it in WTP 1.5rc4. It works with Dynamic Web project as absolute and relative path. It works in Tomcat project (Sysdeo plugin) only if path to include is relative ../include.jsp but doesn't work if path is absolute like: /include.jsp
This bug was moved to 'closed' state, since it has been in the 'remind' state so long, it is assume to no longer be an issue, so the bugzilla is likely no longer useful or need further attention. Feel free to re-open, or open a new bug, if this semi-automatic processing was done in error.
Reopening, in order to put into a valid closed state as remind is now deprecated, and closed, remind, does not make much sense.
Resolving as won't fix, as these had previously been closed out, if this is incorrect, please provide more data and reopen. Thanks,
Re-closing appropriately with valid state.
I'd like to add something to this issue. I'm using eclipse at our company to see if is a valid replacement for Netbeans while developing JSP based web-apps. I'm running into the same trouble. With @includes and jsp:includes Ctrl-click doesn't work and vars declared in @includes aren't available in the page. This off-course when the includes are specified from the root of the website with '/'. Relative paths work just fine. Is there any more information available on this issue I would really like to know because nothing would satisfy me more than giving Netbeans a permanent farewell in our dev process... If this issue isn't resolved than I am convicted to Netbeans again. (eclipse 3.2.2 / sysdeo 3.2.1)
As mentioned in comment 12, having a sample project illustrating the JSP and fragment file relationships would go a long way toward helping to fix the spots that people are still wanting to be worked on.
No problem, I will post this asap. This will be a Eclipse/tomcat project with some @includes and jsp:includes.
Removing the hotbug flag from the summary because it makes me worry every time a notice shows up in my inbox :)
Created attachment 163156 [details] Sample project using include directive of depth two Tomcat downloaded from this page: http://www.coreservlets.com/Apache-Tomcat-Tutorial/eclipse.html
Added sample project. Could you please re-open this bug?
I'd like to echo that this bug happens to me in Galileo SR2 as well as the latest nightly Helios JEE build. It's very frustrating to have nearly all my jsp files erroring on variables from includes, especially since Bug 174114 prevents me from disabling jsp validation all together.
(In reply to comment #24) > Added sample project. > > Could you please re-open this bug? No, I'm going to open a separate bug (bug 314385) because this seems to only affect XML-formatted JSP files while this bug was about the original syntax.
