- This topic has 3 replies, 3 voices, and was last updated 18 years, 2 months ago by
.
-
Posts
-
On one of our JSP pages, the MyEclipse JSP editor gives a wrong warning about a variable nog being read. The warning is given on a usebean tag:
<jsp:useBean id="example" class="com.mycompany.examplebean" scope="page"/>The exact message is “The local variable example is never read”.
After the useBean tag there is a bunch of scriptlets mixed with HTML, and after that we have:
<jsp:setProperty property="test" name="example" value="abc"/> <c:set var="foos" value="${example.foos}"/> <c:forEach var="foo" items="${foos}"> ...So, in this case the bean ‘example’ is definitely read, namely by the c:set tag. So the warning is wrong.
This is a known bug. If the warnings are cluttering the problems view, you can filter out the file from validation using the new Exclusion functionality (either under project properties, then MyEclipse > Validation > Exclusion, or right click on the file and go to MyEclipse > Exclude from Validation)
Wouldn’t is be perhaps a better solution to be able to exclude a specific type of validation? A user could then opt to exclude only these types of validation warnings. Alternatively, for every warning which has know problems, it might be helpful to notify the user about this.
E.g. The warning would then become something like “The local variable example is never read. Note! There are known problems with the accuracy of this warning.”
In our case this would be helpful. We have some interns working in our web layer, and its quite hard to explain to them which warnings should be taken seriously and which not.
Wouldn’t is be perhaps a better solution to be able to exclude a specific type of validation? A user could then opt to exclude only these types of validation warnings. Alternatively, for every warning which has know problems, it might be helpful to notify the user about this.
Absolutely it would be, it’s just the time to implement this that is the problem. We are building ontop of WTP, so any changes we make outside the WTP stream that relies on code there, now needs to be protected against breaks *every* release. Which also means anytime a user updates WTP out from under us, bam, that feature breaks.
We have included the validation exclusion flag (for all validation) and you can turn off more specific validations (a little too coarse for what you are asking), but we don’t yet have control over *all* the validations that are being run as part of the “JSP validator”. We can certainly see the value to doing this though.
