Community
Participate
Working Groups
on WTP 3.2M5 The following in my JSP is being marked as an EL Syntax Error: ${header["Accept"]} The code executes fine. Other uses of the ["foo"] notation show up as syntax errors as well. If I change it to ${header[0]} it doesn't complain.
I'm also seeing a similar error with this line ${fn:join(row.errorProofing, ',')} I get the highlights on the single quotes.
I see a similar problem in this line ${fn:join(row.errorProofing, ',')} warnings highlight on the single quote. using eclipse 3.2RC1, webtools 1.5
May be related: ${(1 < 0) ? "YES" : "NO"} produces an EL Syntax Error as well. I got this example out of Core Servlets page 494 so I presume it's valid. Sometimes 1 and 0 need to be complex objects (ie request.header) to trigger the yellow squigglies but they stick.
Still seeing this in RC5. Perhaps related, but in the last month references to param collection elements seem to flag as errors incorrectly as well, ie: <option ${(param.foo eq "0")?"selected":""} value="0">Foo</option> Since the string collection accessor is also failing there seems to be no workaround to the problem.
Any idea on when this might be fixed? I recently stopped using the BEA Workshop JSP plugin (which does validate correctly) and now noticed that my project has several hundreds of errors. This makes it quite difficult to find "real" warnings. Suggestion: Add "Ignore warning" option to the context menu of the Problems view.
Adding my post-IBM email..this is still a big annoyance to me as most of my JSPs end up showing false errors.
When I write the following code in a JSP page in Eclipse, it gives a warning, "EL Syntax Error". ${param['user']} It also says that the word 'param' is not correctly spelled and underlines it with a yellow squiggly. The two "EL Systax Error" messages are show at the two ']'. I'm using Eclipse Europa for JEE developers. I receive the expected output when the page is loaded on the browser. It is extremely intimidating when a 100% correct JSP page shows several wrong warning messages.
This bug is more than two years old and still present in Eclipse 3.4. Any progress regarding this annoying behaviour? Regards,
I have a simple JSP, see below. [<a href="<%= request.getContextPath()%>/${backToRegister != null ? 'register' : 'enquire'}/home.do" >${backToRegister != null ? 'Go to Registration' : 'Back to main'}</a>] It is giving me an error "EL Syntax Error". Description Resource Path Location Type EL Syntax Error failEnquire.jsp xxx line 0 JSP Problem It is making a red squiggle mark before the second ":". ${backToRegister != null ? 'Go to Registration'<red_mark_here>: 'Back to main'}
Just wanted to +1 this issue. I've got: User Login from ${header["host"]} with red markings under the "
Created attachment 115620 [details] patch Adding a patch to fix the EL validator so that it considers all of the content of the EL container and not just regions that are of the type JSP_EL_CONTENT.
Nitin, could you please take a look at this patch before I release it?
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. Without these changes, the JSP EL validator will incorrectly identify problems in EL regions that contain some kind of EL syntax and a string literal. * Is there a work-around? If so, why do you believe the work-around is insufficient? Yes, the work-around is to ignore EL Syntax problems in the JSP Validation preferences. The drawback to this is that real EL syntax problems will be ignored as well. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? No JUnits, but the fix has been tested manually using the numerous failing EL regions posted in the comments of the bug. * Give a brief technical overview. Who has reviewed this fix? Before, the JSPELValidator would skip quoted regions in JSP EL content, thus the validated EL content would be incomplete and syntax validation would fail. Now, the validator looks at the content of the EL region as a whole instead of splitting it up into regions. Nitin has reviewed this fix. * What is the risk associated with this fix? Minimal. The change only affects the EL validator and the text that it validates.
*** Bug 252336 has been marked as a duplicate of this bug. ***
Looks good. For the technical information, we currently break up any EL regions into different pieces depending on the presence of quotes. Without this patch, only the segment before the first quote would be sent to the EL parser. The patch changing this to properly use the entire EL content.
I think this is great and a needed fix, but can you comment on one (potential) issue. I'm wondering about "runaway code" in loops such as that below (from your patch) ... what if there is no 'close' region (yet) ... seems it might slow down typing in a large file, until the user types '}'. I don't recall (but Nitin might :) it seems like in some cases we put in some huge maximum regions we'd check, like 500? 1000? That at least prevents an apparent hang if someone has a megabyte jsp file, or similar. + /* Find the EL closing region, otherwise the last region will be used to calculate the EL content text */ + while (elRegions != null && elRegions.hasNext()) { + elRegion = (ITextRegion) elRegions.next(); + if (elRegion.getType() == DOMJSPRegionContexts.JSP_EL_CLOSE) + break; +}
(In reply to comment #16) > I think this is great and a needed fix, but can you comment on one (potential) > issue. I'm wondering about "runaway code" in loops such as that below (from > your patch) ... what if there is no 'close' region (yet) ... seems it might > slow down typing in a large file, until the user types '}'. I don't recall (but > Nitin might :) it seems like in some cases we put in some huge maximum regions > we'd check, like 500? 1000? That at least prevents an apparent hang if someone > has a megabyte jsp file, or similar. > > > + /* Find the EL closing region, otherwise the last region will be used to > calculate the EL content text */ > + while (elRegions != null && elRegions.hasNext()) { > + elRegion = (ITextRegion) elRegions.next(); > + if (elRegion.getType() == DOMJSPRegionContexts.JSP_EL_CLOSE) > + break; > +} Adding limits sounds reasonable, but just to assuage any concerns, the JSP parser only divides the EL into quoted and non-quoted segments. It's not a full syntactic breakdown, so the common case would be a somewhat small number. Nick, please attach an updated patch with a limit of 1000 or so for the while loop.
Created attachment 116434 [details] patch with a max number of regions in the loop Added a check of 1000 regions before exiting the loop.
Created attachment 116451 [details] patch for more than 1 EL region in a container Removed the break from the conditional that checks EL content because there may be more than one EL expression in the container. For example, <a href="${fn:trim('http:// ')}${fn:trim('www.eclipse.org') }">Eclipse</a>
yes, I'm fine with this.
Released to 3_0_Maintenance.
In RC2.
Released to HEAD.
Verified in wtp-R-3.0.3-20081113203138.
*** Bug 239913 has been marked as a duplicate of this bug. ***
*** Bug 156034 has been marked as a duplicate of this bug. ***
*** Bug 238752 has been marked as a duplicate of this bug. ***
*** Bug 149392 has been marked as a duplicate of this bug. ***
*** Bug 206704 has been marked as a duplicate of this bug. ***
*** Bug 112527 has been marked as a duplicate of this bug. ***
