How to configure project in Eclipse so that jsps can be validated properly including <%@page import="...%>in <@include file="...">

StackOverflow https://stackoverflow.com/questions/21735430

Question

Let there be a (Liferay hook plugin) eclipse project xyz-hook. And let there be the file a.jsp

<% @include file="/html/portal/init.jsp" %>
<% InitImportedClass.yxz(); %>

and let there be the included init.jsp in another (referenced) project.

<% @page import="de.company.InitImportedClass" %>

For a.jsp in project xyz-hook we get a warning in line 1

Fragment "/html/portal/init.jsp" was not found at expected path /xyz-hook/src/main/webapp/html/portal/init.jsp

and an error in line 2

InitImportedClass cannot be resolved

Is there any way to tell Eclipse to go looking for init.jsp in the other project?

The project (Liferay portal trunk) containing the init.jsp is already referenced. I also created an synthetic jar containing the jsp as well, added it to the local maven repository and as dependency to project xyz-hook.

PS: For those wondering, this is a typical setup for Liferay hooks when replacing jsps, that are provided by the portal core.

PPS: I'm aware that I could deactivated jsp validation altogether, but that is something I'd like to avoid, since otherwise imports that are really missing won't be shown as error either.

Was it helpful?

Solution

I'd very much welcome such a feature, but according to my last conversations about it, it will be really hard to solve and requires major changes in quite a few components. Given that the jsp editor is somewhat fragile already (sometimes it's showing validation errors that are not there) I don't see anybody attacking it in the near future. But I'll take this as a cause to nag again. (You might want to post a feature requests on https://issues.liferay.com/browse/IDE or find an existing one and support it)

However, there are some workarounds:

With the <liferay-util:include /> jsp-tag you can specify a servletContext and include another JSP from your own hook. This will run in the specified webapp's classloader and eclipse can handle that one well. In your jsp-hook you still need to deactivate jsp validation, but the remaining JSP is just a few characters doing the include business, and that's quite ok.

You'll have a bit more work getting all the context etc., but if you are doing some heavier work, this might be an option. You can also use custom classes from a hook - which you typically can't when you introduce a new jsp into the portal classloader.

Pseudocode example:

In your hook, overriding jsps from the portal, e.g. in my-hook/custom-jsps/html/portlet/navigation/view.jsp

   <%-- omitted taglib includes --%>
   <liferay-util:include 
         page="/jsp/navigation/view.jsp" 
         servletContext="<%=this.getServletContext().getContext("/my-hook")%>" />

this will override Liferay's default jsp for the navigation portlet with your own implementation. However, it obviously doesn't do much, but includes /jsp/navigation/view.jsp which it will find within your own hook (note: /custom-jsps contains the jsps that override the portal's - files in /jsp will be served within the hook's context:

in my-hook/jsp/navigation/view.jsp

   <%-- omitted taglib includes --%> 
   <ul>
   <li>build</li><li>your</li><li>navigation</li>
   </ul>
   <!-- you also have access to classes introduced by your hook -->
   <%=CustomClassInHook.doSomething() %>     

The drawback is that you'll have to "repeat" the initialization that every Liferay jsp typically gets on your own - e.g. import statements, make themeDisplay available etc.

Also, be aware: Above is pseudocode. I've just typed it here from some (pen&paper) notes, not ran it. So it might require a bit more work and have other drawbacks or shortcomings.


Another possibility is to develop complex overridden jsps within Liferay's sourcecode and - when done - carry them over into your own hook. You'll get a build-time hit if you need to rebuild Liferay (but who rebuilds for a jsp change?) but you get all the IDE luxury

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top