[Keith Fetterman]

Can you help me? I am running into name collision problems when trying to correct JSP validation errors in MyEclipse.

I have many JSP files that include other JSP files. These “included” JSP files won’t validate in MyEclipse because they use variable names that were defined in the parent JSP file (the file that included them.) These files are being included using the syntax:

<%@ include file="headerFramePage.jsp" %>

I have been setting the variables defined in the parent file into request attributes and then fetching them back out in the files that are being included. This is working except I have to use a different name when I fetch them because the included files are in the same scope as the variable defined in the parent file when the Java application server compiles the JSP page. This is a real pain, but it works. (There is also a lot of unnessary set and getting of request attributes.)

But, I am running into problems using <jsp:useBean /> due to name collisions at Java app. server compile time.

For example, a parent JSP file has the following tag defined:

<jsp:useBean id="headerBean" class="com.marinersupply.bean.HeaderBean" scope="session" />

The files being included reference the variable “headerBean”. MyEclipse validation fails for the included files, because MyEclipse doesn’t have “headerBean” defined in the files being included. It is defined in the parent file.

I can’t define <jsp:useBean id=”headerBean” /> again in the included files because they fail when the app server compiles the JSP file because the variable “headerBean” is declared twice in the same scope, once in the parent file and once in the included file.

Any suggestions on solving this delima would be greatly appreciated.

Thanks,
Keith

[Riyad Kalla]

I have been setting the variables defined in the parent file into request attributes and then fetching them back out in the files that are being included.

Can I ask why? Considering how @include works (simply inlines the file’s contents) that is a lot like doing this:

private static Map map = new HashMap();

public static void main(String[] args)
{
  map.put("args", args);

  // inlined code start
  String[] arguments = (String[])map.get("args");
  // inlined code end
}

This is a real pain, but it works. (There is also a lot of unnessary set and getting of request attributes.)

As I mentioned, it is not a good idea to do this… I’m guessing the only reason you are doing this is to get nice autocomplete and such in the fragment files, right?

MyEclipse validation fails for the included files, because MyEclipse doesn’t have “headerBean” defined in the files being included. It is defined in the parent file.

I think the fundamental problem here underlying this entire post is that you are not naming your included files with a .jspf extension which is dictated by the JSP spec as the extension to use for “JSP Fragments” or now called “JSP Segments”, more specifically: JSP pages that cannot be compiled/run on their own, but are meant to be included in larger pages.

Any suggestions on solving this delima would be greatly appreciated.

Yes, follow the spec’s suggestion:

1) Rename all your include files to .jspf files
1.5) MyEclipse will stop validating these files because it *knows* they are not valid JSP pages by themselves.
2) Get rid of all the request.setAttr/getAttr code and just reference the vars directly in your included pages. During coding time it won’t give you autocomplete, but after the page is compiled/run it will work as it should.

[Keith Fetterman]

I have been setting the variables defined in the parent file into request attributes and then fetching them back out in the files that are being included.

Can I ask why? Considering how @include works (simply inlines the file’s contents) that is a lot like doing this:
[…]

As I mentioned, it is not a good idea to do this… I’m guessing the only reason you are doing this is to get nice autocomplete and such in the fragment files, right?

I was only doing this because MyEclipse was displaying validation errors. I knew that @includes just inlined the included JSP files because the pages work with our Java application server (resin 3.x)

I think the fundamental problem here underlying this entire post is that you are not naming your included files with a .jspf extension which is dictated by the JSP spec as the extension to use for “JSP Fragments” or now called “JSP Segments”, more specifically: JSP pages that cannot be compiled/run on their own, but are meant to be included in larger pages.

You are correct. When this application was originally developed, the “.jspf” extension had not been defined yet to identify JSP files that were fragments.

Yes, follow the spec’s suggestion:

1) Rename all your include files to .jspf files
1.5) MyEclipse will stop validating these files because it *knows* they are not valid JSP pages by themselves.
2) Get rid of all the request.setAttr/getAttr code and just reference the vars directly in your included pages. During coding time it won’t give you autocomplete, but after the page is compiled/run it will work as it should.

Thanks for your help on this. And thanks for the timely response. I will also go back and review the 2.0 spec of JSP.

[Riyad Kalla]

When this application was originally developed, the “.jspf” extension had not been defined yet to identify JSP files that were fragments.

I feel for you in this predicament… I think you worked around the problem in the best way you could, but I guess now is as good a time as any to go the segment route…

[Keith Fetterman]

Renaming the files that won’t compile to *.jspf is working great. Thanks.

I have a question though. When I validate a *.jsp file that uses included *.jspf files, I receive an error because I haven’t edited the file yet to change the filenames of the included files from *.jsp to *.jspf.

When these errors show up in the parent JSP file, why does the error always show up at the top of the file? It says that it can’t find a line number. Also, it only shows a single error for the first file that needs to be renamed. If the parent JSP file has three includes that need to be renamed, I have to edit and validate the file three times, once for every include that needs to be fixed.

Unrelated question. I notice that 3.8.4 is out. I am currently running 3.8.3. Can I update via the update feature in Eclipse, i.e. “Help > Software Updates > Find and Install…” or should I down load the installer from the MyEclipse downloads page?

Thanks for your help.

Can I update it via the

[Riyad Kalla]

Renaming the files that won’t compile to *.jspf is working great. Thanks.

Glad to hear it!

When these errors show up in the parent JSP file, why does the error always show up at the top of the file? It says that it can’t find a line number.

This can be frustrating, there is already a bug filed against these ‘illpositioned compile errors’. I’m hoping it is something simple and can get knocked out soon, but I have a feeling it might need to wait until we move back to using the JDT compiler instead of the Javac compiler for compiling JSP pages, which is a major change I’m told.

Unrelated question. I notice that 3.8.4 is out. I am currently running 3.8.3. Can I update via the update feature in Eclipse, i.e. “Help > Software Updates > Find and Install…” or should I down load the installer from the MyEclipse downloads page?

Yes you can, double check the MyEclipse Announcements forum at the top, I just added the link for the update site that you need to use for it to work. Just make sure to restart with -clean after installing the update atleast once.

[Matthew McCullough]

I’m using MyEclipse 3.8.4 on Eclipse 3.0.1

I’m still getting validation errors on JSPF files, though they are set as a “fragment extension type” just as the MyEclipse defaults set them to be.

For example, I’m getting the following validation error on the file listed below…

Severity Description Resource In Folder Location Creation Time
1 Invalid location of tag (table). reportsHeader.jspf WebAppMacroTool/webapp/src/webapp line 15 February 22, 2005 4:05:29 PM
1 Invalid location of tag (hr). reportsHeader.jspf WebAppMacroTool/webapp/src/webapp line 53 February 22, 2005 4:05:29 PM

<%@ page
import=”com.echostar.macrotool.util.*”
import=”com.echostar.macrotool.model.*”
%>

<%@taglib uri=”/WEB-INF/tld/struts-bean-1.1.tld” prefix=”bean” %>
<%@taglib uri=”/WEB-INF/tld/struts-html-1.1.tld” prefix=”html” %>
<%@taglib uri=”/WEB-INF/tld/struts-logic-1.1.tld” prefix=”logic” %>

<jsp:useBean id=”profile” scope=”session” class=”com.echostar.macrotool.model.SecurityProfile” />
<jsp:useBean id=”user” scope=”session” class=”com.echostar.macrotool.model.User” />

<table border=”0″ width=”100%” height=”50″ class=”tbodyfree”>
<tr>
<td width=”50%”></td>
<% if(com.echostar.macrotool.util.SecurityManager.allowsRead(user, SecurityProfile.ManagReport)){ %>
<% if((request.getParameter(“caller”) != null) && (request.getParameter(“caller”).equals(“usage”))) { %>
<td>
<html:link href=”reports.do?action=Managerial”>
<b>Managerial Reports</b>
</html:link>
</td>
<% } else {%>
<td>
<b>Managerial Reports</b>
</td>
<% } %>
<% } %>
<% if((com.echostar.macrotool.util.SecurityManager.allowsRead(user, SecurityProfile.UsageReport)) &&
(com.echostar.macrotool.util.SecurityManager.allowsRead(user, SecurityProfile.ManagReport))){ %>
<td>
 | 
</td>
<% } %>
<% if(com.echostar.macrotool.util.SecurityManager.allowsRead(user, SecurityProfile.UsageReport)){ %>
<% if((request.getParameter(“caller”) != null) && (request.getParameter(“caller”).equals(“manag”))) { %>
<td>
<html:link href=”reports.do?action=Usage”>
<b>Usage Reports</b>
</html:link>
</td>
<% } else {%>
<td>
<b>Usage Reports</b>
</td>
<% } %>
<% } %>
<td width=”50%”></td>
</tr>
</table>
<hr>

[Riyad Kalla]

These look to be HTML validation errors, have you turned on HTML validation?

[Matthew McCullough]

Riyad,

Yes, I’ve turned on HTML validation. So, are only JSP errors are suppressed in fragments?

Is there any way to suppress HTML errors just on those files specifically with a file type of JSPF? Since JSPFs are “page fragments”, won’t they generally contain “misplaced” html elements, much like the error messages that I’m getting?

Thanks,
Matthew

[Riyad Kalla]

So, are only JSP errors are suppressed in fragments?

Yes the idea of a “Fragment” is for the benefit/care of the JSP editor as this is an entity described in the JSP specification. So if you have the HTML validatored turned on, it will run against all the files that can contain HTML.

Is there any way to suppress HTML errors just on those files specifically with a file type of JSPF?

Not currently.

Since JSPFs are “page fragments”, won’t they generally contain “misplaced” html elements, much like the error messages that I’m getting?

This is true and this is also part of the problem of allowing the overlapping of HTML and JSP validation… the HTML validator doesn’t know about “Fragments”, it also has no idea what a <jsp:include> or a <%@include%> directive mean… so if you validate your JSP page, the JSP validator will combine all the framents and then validate the final page, the HTML validator will run against pages and fragments alike, with no knowledge of how to combine them and will inevitable run into problems.

For example, there are people that like to open tags in the main page, and close them in the fragment… the HTML validator would mark BOTH pages with problems as it doesn’t have the ability to combine the JSP pages and it’s fragments before running.

And no this isn’t an easy thing to do and likely wouldn’t be supported (just due to resource balancing, and the time it would take… if enough people wanted it and we freed up some bandwidth we would certainly look into it).

Sorry for the bad news Matthew, this is why we ship the HTML validator off by default, because MyEclipse is a J2EE tool, so we assume most people will be using it for JSP development and not valid HTML development (which, as you found, can give drastically different results as far as ‘valid pages’ is concerned).

[Author]

Posts