- This topic has 8 replies, 3 voices, and was last updated 17 years, 9 months ago by
.
-
Posts
-
I’m using MyEclipse 5.1 and in a project I have that uses JSP with Struts tags I get validation errors like this:
<logic:iterate id=”cv” collection=”<%=location.getRelatedPaths()%>” type=”CategoryView[]”>
<tems:taxonomyPath path=”<%=cv%>”/>
</logic:iterate>The cv in the middle line has the validation error, “cv cannot be resolved.”
This JSP compiles and works perfectly on the server and has no other validation errors. Any JSP in this project that uses a Struts tag and an ID gives errors when the ID is used from a scriptlet.
Your help is much appreciated!
Thank you,
AustinAustin,
This is a known issue, it’s because the JSP parser doesn’t evaluate tags, so it doesn’t know the logic:iterate tag creates a tag-scoped variable called “cv”, so it doesn’t recognize it in the scriplet. We are evaluating solutions to this internally.Did this issue just materialize because it was working for us then we refactored our project structure and it materialized.
OK. I don’t know what this means or even if it is right but when I added the project containing the source for the type of the tag-scoped variable the errors went away and i even got code-assist on the type with CTL-Space so I know it was resolved. When I included the classes in a library jar attached to the project instead they come back. So it is not an always kind of thing.
Still have some edge cases where it is a problem like placing the tag-scoped variable inside a javascript function — but I probably deserve that one for such an awful code construct…
mbucknam,
Give your first example… you mean that if CategoryView is from a JAR, autocomplete on CV won’t work, but if it’s in the project, it *will* work?Yes. that is correct. I have gone back and validated it further. If the source for CategoryView is in the enclosing project you have goodness. If it is in another project on the build path you have goodness. If it is from a jar on the build path you have no goodness. Even if you attach the source to the jar you still have no goodness. So I think the parser is looking at projects but not library jars. You cannot even use something like a type=”java.lang.String” since it is technically attached as a library jar file.
Hopefully this breadcrumb will help isolate the problem.
I tried to reproduce this locally and couldn’t… can you import this project into your workspace, and open the JSP and try autocomplete in each loop? Once loop uses a type from rt.jar and the other uses a class from the project itself. I got autocomplete with both scriplets.
Maybe the test case is wrong?
Riyad:
I get unpredictable behavior so I don’t know what to say. Here is what I did: I downloaded your workspace and imported it into an EXISTING workspace with build automatically turned OFF. It is a very large workspace with several huge projects in it with tons of inter-dependencies and external dependencies. I selected build project after importing it and had errors in the JSP. Neither scriptlet would validate. Manually selected MyEclipse –> validate, still had errors. So I switched build automatically back on which triggered a massive long-running rebuild of all the projects in the workspace. After it finished running the validation errors were gone and autocomplete works — not only in your sample project but in my web projects where there were previously errors when build automatically was turned off and I was individually building the projects.When I import the project into a clean workspace it works right away. I’m the member having the BEA weblogic JSP debugger source problems with the huge project workspace so I wonder if some of these problems are, again, due to the size of the project?
Ahh… well if you really do have enormous projects, you could be running out of memory when the indexer or parser are running. Either heap space (-Xmx) or permGen space (-XX:MaxPermSize=128M)
Our default optimized startup string for the VM is this:
-vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128Mbut assuming you have 1.5GB or more of physical ram on your computer, you might try this and see how things perform (don’t forget to restart using -clean on your command line args):
-vmargs -Xms256M -Xmx768M -XX:PermSize=128M -XX:MaxPermSize=256MWith such large memory settings though, your GC cycles may run longer, so if you notice long pauses after a lot of coding, my guess is those are the GC cycles cleaning up. Although Sun’s different GC algorithms have gotten so good recently, you could try specifying another GC algorithm like this:
-vmargs -Xms256M -Xmx768M -XX:PermSize=128M -XX:MaxPermSize=256M -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabledthose would probably be the most aggressive optimizations to try. I haven’t tested these personally however.
