Community
Participate
Working Groups
We use the official 2.4 construct "include-prelude" to prefix all jsp's with a shared jspf that includes all taglib directives. (kind of like <jsp:include page="/taglibs"/>, but without having to provide it in the jsp. The jsp editor does take these taglib directives into account and thus fails to compile and code-complete jsp tags. This bug is severe because it means we would be back to having directives in very single jsp, most painful to change directives in large apps with 400 jsps like we have. This is valid 2.4 web-xml: <jsp-config> <jsp-property-group> <display-name>taglibs</display-name> <url-pattern>*.jsp</url-pattern> <include-prelude>/taglibs.jspf</include-prelude> </jsp-property-group> </jsp-config>
Nitin, please evaluate .. is this related to the other fix we just released today?
No, this is unrelated. It appears to be a part of Servlet 2.4 / JSP 2.0 that we don't yet support, like the content type values that declare new name patterns for JSP files.
CCing David since I'm not sure he got the notice for my previous comment.
Of course, thanks Nitin, I'm skim reading too much. Wolfgang, this does sound important, so we'll evaluate for 1.0. I'm changing version to .7, since its supposed to be either the version reporter was using when found, or the verison its fixed in. We'll update this bugzilla as we update and prioritize to see if it can fit in M9, but won't plan to fix on .7 base.
Is this related to the bug with defining taglib directive in an include file and jsp editor cannot recognize the taglibs in the inclusing jsp? <@ include file="mytaglibs.jsp" %> <c:out ...
Naci, no, it has to do with new abilities in the deployment descriptor, not anything within the JSP source itself.
(In reply to comment #6) > Naci, no, it has to do with new abilities in the deployment descriptor, not > anything within the JSP source itself. Nitin, Does this mean that i would be able to get content assist for methods defined in my include files ("<%@include file") from my JSP ? This doesn't seem to be working for me. Thanks, Arun
(In reply to comment #7) > Does this mean that i would be able to get content assist for methods defined > in my include files ("<%@include file") from my JSP ? > This doesn't seem to be working for me. Yes, although there's another bug having to do with the internal translation being assembled incorrectly when fragments are involved. Content Assist may not return the correct proposals in that case. Phil, has that bug been corrected in 1.5?
Yes that problem is fixed. Example files where it's not working?
Created attachment 62351 [details] initial test implementation The attached patch implements a DeploymentDescriptorPropertyCache to keep the key values of a web.xml's jsp-config property-groups available in memory (as a soft referenced set of objects based on the web.xml's workspace path) for Java translation and the content model. For now the include-coda files are ignored by the tag content model but included in the Java translation, and I have yet to evaluate the performance impact. I'm also not sure about adding yet another resource change listener into the jsp.core plugin--even if they're all POST_CHANGE we're up to 4 with this addition.
Released for RC0.
The solution for this bug only takes into account the first jsp-property-group element. For web.xml files that have multiple jsp-property-groups, the jsp editor won't honor all elements, just the first. Since I can't reopen this bug I've added a new one here: bug#191483
verified in wtp2.0 RC4 200706212235
