- This topic has 14 replies, 3 voices, and was last updated 20 years, 2 months ago by
.
-
Posts
-
I’ve followed the post “JSP/HTML editor gives me compilation errors, eg “this variable cannot be resolved” for an included JSP file.” And have a similar problem with *some of* my includes.
I get a number of “cannot resolve symbol: symbol : variable qty” errors within a handful of JSPF include fragments. Each of these files has a red cross against it in Package Explorer yet when I look at the jspf file two things can be noted: (1) the variable “qty” is not referenced or mentioned in the fragment and (2) each “offending” JSPF includes a further JSPF where the variable is defined.
Example
A.jsp contains <%@ include file=”B.jspf” %>
B.jspf contains <%@ include file=”C.jspf” %>C.jspf contains the following references to “qty”:
<bean:size id="qty" name="someList"/> <bean:message key="<%= some_description %>" arg0="<%= qty.toString() %>"/>Within the problems tab, I get the “cannot resolve…” message but it points to “B.jspf” as the offending resource when presumeably this should be “C.jspf”. The line that is being complained about is the bean:message containing the scrptlet <%= qty.toString() %>.
Related to this in other (none fragment) JSP files I get a little black warning marked against the righthand edge of the editor saying “sn cannot be resolved” for the following scriptlet:
<bean:write name="sn"/> <html:hidden property="skillNames" value="<%= sn %>"/>I am running 3.8.1+QF20040825, and I have Preferences/MyEclipse/Editors/JSP/JSP Fragment Extensions set to “jspf” (without the quotes).
Jonathan
Jonathan,
I just created the following setup:
1) New Web project
2) Add Struts capabilities
3) Create 3 new JSP files:A.jsp
<%@ page language="java" %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <body> <%@ include file="B.jspf" %> </body> </html>B.jspf
<%@ include file="C.jspf" %>C.jspf
<%@ page language="java"%> <%@ taglib uri="http://jakarta.apache.org/struts/tags-bean" prefix="bean" %> <%@ taglib uri="http://jakarta.apache.org/struts/tags-html" prefix="html" %> <%@ taglib uri="http://jakarta.apache.org/struts/tags-logic" prefix="logic" %> <%@ taglib uri="http://jakarta.apache.org/struts/tags-tiles" prefix="tiles" %> <%@ taglib uri="http://jakarta.apache.org/struts/tags-template" prefix="template" %> <%@ taglib uri="http://jakarta.apache.org/struts/tags-nested" prefix="nested" %> <bean:size id="qty" name="someList"/> <bean:message key="some_description" arg0="<%= qty.toString() %>"/>I don’t have error markers anywhere. Can you try this and see if you get the same? OR maybe I misunderstood your problem?
Also about the black reconciler marker (that is the RIGHT margin) we are aware of shortcommings with it resolving variables defined by tags, and that should be fixed soon. What I”m worried about here is fake LEFT margin errors, this is generated by the Jasper2 JSP compiler, so these SHOULD be the same as you owuld see in Tomcat.
Mmm… Firstly the easy bit – yes I mean the black marker on in the right hand margin. The main point about this thread is the red markers down the left hand side.
Ok, I have tried the above suggestion and found the following. Without the tablib directive I get a red cross – however the red cross appears in my parent JSP (A.jsp). If I add the relevent taglib directive anywhere in the list of JSPs then the red marker goes away. Unfortunately this isn’t what I am seeing in my main project. Specifically the red marker appears in the intermediary JSPF (B.jspf) not the parent nor the leaf.
Within my project my parent jsp (aka A.jsp) contains the tablib directives and the JSPFs do not. So here’s a number of tests I’ve run:
A.jsp contains taglibs only
Validation of A.jsp: OK
Result: red cross in B.jspf (Package Explorer)A.jsp & B.jspf contains taglibs
Validation of A.jsp: OK
Result: red cross in B.jspf (Package Explorer)A.jsp & C.jspf contains taglibs
Validation of A.jsp: OK
Result: red cross in B.jspf (Package Explorer)A.jsp, B.jspf & C.jspf contains taglibs
Validation of A.jsp: OK
Result: red cross in B.jspf (Package Explorer)As for Tomcat and Jasper, I deploy my WAR file to Tomcat 5.25 and it works quite happily…
Any more thougts? I am intreged that with a new dummy project I don’t get the red crosses, where as I do with my real project. Could this point to a set up problem/difference? If so what do you think I should look at? Or is that just a red herring.
Help appreciated.
Jonathan
Jonathan,
Does your A.jsp page not actually use the taglib, but instead the B page does? Or is the setup technically equivalent to what I had (where B is just a include-conduit and doesn’t do anything?).Also can you try creating a new Web mod project, and add Struts support, then move the real A, B and C pages over into the project, and then any other pages necessary to get them to compile correctly. Are all the errors gone? If so, try and drag the WHOLE project into the new web project… are all the errors gone? Did you try chanting? (this is a weird one…)
A.jsp uses <bean>
B.jspf uses <bean>
C.jspf uses <bean>In my actual code A does the main work, B is pretty much a conduit and C does a little bit more work (basically setting up some page socped beans depeneding on certain conditions).
I’ll try copying the files into my new project and tell you what happens. Chanting!? I’ll pretty much try anything once… (not sure the boss’ll be too pleased though:)
Jonathan
I tried this and my JSPF errors disappeared !?
I do now have half a dozen JSP files with scriptlets in them that are highlighted with red crosses in Package Explorer and red crossed in the right margin in the edit window.
Tomorrow I’ll go back to my original project and try and see what’s what. Do you have any suggestions as to which config/property/ini files I might want to look at to compare and contrast between the two projects?
Jonathan
Jonathan,
This is getting strangeer and stranger… check your .project (for builders and natures) and your .mymetadata files…Stranger? Yes it is! To all intents and purposes my .project and .mymetadatafiles are the same. The .mymetadata files differ only in the id specified within the project-module:
<!-- Main project --> <?xml version="1.0" encoding="UTF-8"?> <project-module type="WEB" name="DEV-JOM-SM" id="myeclipse.1093256825845" context-root="/SM" j2ee-spec="1.4" archive="DEV-JOM-SM.war"> <attributes> <attribute name="webrootdir" value="/SM/web-root" /> </attributes> </project-module> <!-- Temp project --> <?xml version="1.0" encoding="UTF-8"?> <project-module type="WEB" name="Problem1" id="myeclipse.1094136773532" context-root="/Problem1" j2ee-spec="1.4" archive="Problem1.war"> <attributes> <attribute name="webrootdir" value="web-root" /> </attributes> </project-module>The .project files only differ in the order of a coupld of <buildCommand> elements.
Sadly I’ve got to get on (deadlines you know) so I’ll keep trying different things each day and who knows may be one day they’ll disapper…
Do you have an ETA for the “variables defined as tags but used in scriptlets” problem? I am currently pinning my hopes on that resolving everything…
Jonathan (still chanting)
I don’t have an ETA on that specific bug but our 3.8.2 release is focused soley on optimizations and bug fixes and our 3.8.3 (or 3.9) release is all about features and bug fixes (with additional optiomizations)… also I double checked and all the bugs related to reconciler issues and such are high on our TODO list which means they *will* get done no matter what.
Jonathan,
In the latest release with quickfixes applied (3.8.1+QF20040825) there is a preference setting at Window > Preferences > MyEclipse > Editors > JSP called “JSPF fragment extensions”. First, do you see this setting? If so, have you entered a comma-separated list of all suffixes you use for fragments? Does your MyEclipse instance show the version above when you look at the Window > Preferences > MyEclipse page? If not, the issue can likely be resolved by installing the latest quickfix that is referenced as an announcement at the top of this forum and then revalidating your projects.
Hi Scott,
Yes I’m on 3.8.1+QF20040825. And I have the following in the “JSPF fragment extensions” field: “jspf” (without the quotes). I have tried this and “.jspf” and nothing, but all with the same result.
Obscurely, I have a number of JSPF files that do not have red crosses by them. Those files use scriptlet variables (defined in the parent) but do so *without* red crosses.
I’ve done a bit more investigation. My lowest level (leaf) fragment has the following two lines:
<bean:size id="qty" name="list"/> <bean:message key="<%= description %>" arg0="<%=qty.toString()%>"/>And my red cross problem is highlighted as the bean:message line, and the red cross is within the “conduit” JSPF (recall I have a.jsp -> b.jspf -> c.jspf). Now if I play about with the location of the definition of “qty” (in terms of a.jsp, b.jspf) I still get the red cross against line 33 of b.jspf.
I have also tried adding other references to “qty”, so I have replaced the above code with:
<bean:size id="qty" name="list"/> <bean:message key="<%= description %>" arg0="<%=qty.toString()%>"/> <%-- additional line --%> <logic:equal name="<%= form_name %>" property="list" value="<%= qty.toString() %>"></logic:equal>I would expect an additional red cross and error report within the “problems tab”, but I get nothing. Similarly if I remove all references to “qty” the error message remains.
*** Stop Press ***
The red crosses have all gone (and there was huge amounts of rejoicing).What I did was whilst “playing” with my JSPs/JSPFs and MyEclipse settings, I turned off JSP validation and then reapplied it. Turning off got rid of all red crosses (as you’d expect), and turning it back on resulted in… no red crosses appearing!!!
I’ve had a further play (adding in erroneous terms into my JSPF) and can not get the red crosses to reappear.
So I’d deduce two things:
1) My problem is “fixed” (well it’s gone away)
2) From my perspective the problem seemed to be a caching problem within MyEclipse. MyEclipse apparently *didn’t* revalidate (or do anything) with the JSPF fragments during any of my modifications, it only did something when I forceably toggled the project’s JSP validation status. Would that be a reasonable summary?Either way I am back working now.
Thanks
Jonathan
ps I’ve still got the minor (inline) red marks against scriptlet variables within my main JSPs but I can filter those out myself (ignore them until the next MyEclipse release).
Jonathan,
We are glad everytyhing is working now… I thought we had tried a full rebuild which should have gotten rid of incorrect validation issues. Either way, nice job hunting that down and not giving up!
