[Draper]

I just updated to 3.8.4 and now all my JSP pages that used to validate don’t anymore. The error is “can’t resolve symbol: symbol: method getTagHandlerMethodPool()” and some note about can’t assign line number so line number one is used. In order to run, I have to shut off validation. In the actual app, the JSPs all work just fine.

My system is Win XP, eclipse 3.0.0. (The Eclipse update manager doesn’t seem to like our firewall at work and dies 60k into some xxx.doc.isv_3.0.1 file so I can’t upgrade at the moment without totally reinstalling which would be a pain given the number of plugins I have).

To see if it may be my 3.0.0, I upgraded myEclipse at home. There, I am running Mac OS X, and Eclipse 3.0.1. Same project, same problem. The error message was more verbose on the Mac, but was bassically the same.

Is there any path requirement that has changed or any other setting that needs to be made for 3.8.4 validation to run properly?

Thanks.

[Riyad Kalla]

The error is “can’t resolve symbol: symbol: method getTagHandlerMethodPool()”

Where does that method come from? Is your build path missing the J2EE 1.4 Library set? I have a feeling the problem here is that something slight changed in your build path and now the jSP pages can’t compile…

Also double check that your source files ARE getting compiled out to your output folder (use the Navigator view to double check).

Is there any path requirement that has changed or any other setting that needs to be made for 3.8.4 validation to run properly?

No, it is still the same.

[Draper]

Where does that method come from?

I have no idea! Somewhere in the Eclipse/myEclipse environment since I have no reference to it that I am aware of.

Is your build path missing the J2EE 1.4 Library set?

No, it is still included as before.

Also double check that your source files ARE getting compiled out to your output folder (use the Navigator view to double check).

When I do a build, I get no errors that show up in the error view (this error just shows up in the package explorer (each .jsp gets a red marker) and the source file when opened in the editor. The build runs appropriately including the build.xml ant script to build my war file and put it in my particular directory: I am running Jetty but as an embedded servlet/jsp container inside my own application so I don’t use your deployer because I have a slightly different directory structure.

[Riyad Kalla]

When I do a build, I get no errors that show up in the error view (this error just shows up in the package explorer (each .jsp gets a red marker) and the source file when opened in the editor.

Did you actually go into the output dir (WEB-INF/classes) and make sure the class files were there? Sometimes when compiles die, they die silently.

ALso check your log file for errors: <workspace dir>\.metadata\.log, look near the bottom and post anything interesting here.

[Draper]

Did you actually go into the output dir (WEB-INF/classes) and make sure the class files were there?

Used resource view to delete that directory, and then did build. Everything was where it should be.

ALso check your log file for errors: <workspace dir>\.metadata\.log, look near the bottom and post anything interesting here.

I deleted the log contents, and ran everything, one step at a time. After each step I opened the log file and added comments reflecting what each step was. The log contents follow. Needless to say, it doesn’t look very interesting.

<DRAPER: STARTED FRESH LOG>

<DRAPER: WILL NOW START ECLIPSE>

!SESSION Feb 11, 2005 10:11:34.615 ———————————————
eclipse.buildId=I200406251208
java.version=1.4.2_05
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US

!ENTRY org.eclipse.osgi Feb 11, 2005 10:11:34.615
!MESSAGE While loading class “org.eclipse.team.internal.ccvs.ui.console.ConsoleDocument$ConsoleLine”, thread “main” timed out waiting (5000ms) for thread “Worker-0” to finish starting bundle “org.eclipse.team.cvs.ui”. To avoid deadlock, thread “main” is proceeding but “org.eclipse.team.internal.ccvs.ui.console.ConsoleDocument$ConsoleLine” may not be fully initialized.
!STACK 0
java.lang.Exception: Generated exception.
at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:102)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:371)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402)
at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:93)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at org.eclipse.team.internal.ccvs.ui.console.ConsoleDocument.getLines(ConsoleDocument.java:78)
at org.eclipse.team.internal.ccvs.ui.console.CVSOutputConsole.dump(CVSOutputConsole.java:150)
at org.eclipse.team.internal.ccvs.ui.console.CVSOutputConsole.access$1(CVSOutputConsole.java:147)
at org.eclipse.team.internal.ccvs.ui.console.CVSOutputConsole$1.run(CVSOutputConsole.java:118)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:106)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:2749)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2434)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1377)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1348)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:254)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:141)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:96)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:335)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.eclipse.core.launcher.Main.basicRun(Main.java:183)
at org.eclipse.core.launcher.Main.run(Main.java:644)
at org.eclipse.core.launcher.Main.main(Main.java:628)

<DRAPER: START COMPLETE, WILL NOW RUN A VALIDATE OF A JSP>

<DRAPER: VALIDATE COMPLETE (IT FAILED AS DESCRIBED IN MY ORIGINAL POST>

<DRAPER: WILL NOW RUN A “CLEAN” with immediate build of the Project, with NO auto validation>

!ENTRY com.ibm.etools.validation 4 0 Feb 11, 2005 10:13:48.571
!MESSAGE
*** ERROR ***: Fri Feb 11 10:13:48 EST 2005 java.lang.StackOverflowError

<DRAPER: BUILD COMPLETE: WILL NOW RUN APPLICATION (as a Java App under eclipse>

<DRAPER: APPLICATION RAN PROPERLY WITH ALL CLASSES IN THE CORRECT DIRECTORY>

<DRAPER: WILL NOW QUIT ECLIPSE>
<DRAPER: QUIT COMPLETED>

[Riyad Kalla]

Please confirm that this is a Web Project… also are you still getting the same validation error? Is there a way you can create a small test project that exhibits this problem and email it to support@genuitec.com ATTN Riyad and I’ll take a look?

[Draper]

Please confirm that this is a Web Project… also are you still getting the same validation error?

Yes it is a Web Project, always has been. Struts enabled, etc. Yes I am still getting the same validation error.

I don’t know how to create a version that reproduces the problem. For example, I defined a web project choosing just the defaults from the wizard, added the appropriate tlds, and created the following JSP file (cutting up a “tile” from the other project).

<%@ page language=”java”%>
<%@ taglib uri=”/WEB-INF/struts-html.tld” prefix=”html” %>
<%@ taglib uri=”/WEB-INF/struts-logic.tld” prefix=”logic” %>
<%@ taglib uri=”/WEB-INF/struts-bean.tld” prefix=”bean” %>
<style type=”text/css”>
p.headerPanel
{
font-family:Arial,Helvetica,Geneva,Swiss,SunSans-Regular;
font-size:16px;
font-weight:bold;
}
</style>

<p class=”headerPanel”>ABC</p>
<table class=”buttonPanel” width=”50%”>
<tr>
<td class=”spacer”></td>
</tr>
</table>
<table cellspacing=”0″ cellpadding=”0″ border=”0″ style=”height:80%;width:100%;background-color:#f5e9d1″>
<tr>
</tr>
</table>

—- end of file —-

If the project is “stand-alone” (no project references) the validator says it is valid. However, if I add ANY of my projects (Web or not) to the project references and do the validate, it fails. The error message, by the way, has become more verbose. I have no easy way of copying the text of it since it only appears in a hover. Something about org.apache.jsp.testpage_jsp.java not being abstract… (testpage.jsp is the name of the jap so I assume this is the jsp compiler output).

This may be the clue. Since my application embeds Jetty, the base level project upon which all my other projects depend, includes the selected jetty jar files I need as well as other stuff included with jetty. Among other things, when I include my projects, Jasper is also included in the build path. Is there any chance that your newest validator (as I said before 3.8.3 worked fine before the upgrade to 3.8.4) is getting confused by a jsp compiler being in my build path which might cause it to load the wrong compiler for your validator??? Just a thought.

[Draper]

NOTE: I have a solution to my own problem here – found a work around as you will see – but please read and respond to the last paragraph anyway. Thanks…

The clue I mentioned in my prior post turned out to be the solution. I went to the base project with embedded jetty and simply unchecked export on any library that was only needed by the base project. I had been exporting every jar regardless. By unchecking all the apache stuff and jasper, I was able to get the validator to work.

I don’t know whether you ought to consider this behavior a bug in 3.8.4 or not. It seems to me that your validator shouldn’t be damaged by what I export to other projects. In any event, I have a work around now…

One other question. I have had some funky validator related behavior on the Mac. Are there any parts of myEclipse that might get confused by the export (in a project) of jar files that contain J2EE APIs and classes???

[Riyad Kalla]

I don’t know whether you ought to consider this behavior a bug in 3.8.4 or not. It seems to me that your validator shouldn’t be damaged by what I export to other projects. In any event, I have a work around now…

We will investigate to make sure it is properly quarentined. Thank you for nailing this down, I don’t think we ever considered someone having all these libraries in their base project.

Can you tell me the name of the JARs that create the problem so I can create a small sample project and attach it to a bug report?

Are there any parts of myEclipse that might get confused by the export (in a project) of jar files that contain J2EE APIs and classes???

Not that I am aware of, although your findings are very suspect that this might cause issues…

[Draper]

Among the files I stopped exporting are jasper-runtime.jar and jasper-compiler.jar. When I re-export them, the problem returns. So it looks like those are the offending jars. But as I said in my prior post, it looks like a class loader issue that may affect other features.

In general, when you use a servlet container like Jetty embedded in another app, that containing app will have to have all the jars in it. This server application is stand alone (not intended to deployed in an existing web container) so the project must contain all the jars as well as the .war files (struts/tiles based) that implement the user interface. I only mention this because Eclipse (and myEclipse) are good environments for developing any java application, but it also means that it is normal for the project classes to implement some or all of the J2EE APIs. So you may want to look at how your various plugins use class loaders.

As an aside, one quirky problem I discovered in Eclipse itself is that if I change what I am exporting in a project, all the projects in the reference chain have to be manually “refreshed” or it can’t even build… Interesting… I would have expected that to be a type of change that would propogate automatically.

Finally, even though I actually found the problem, I couldn’t have had you not responded so quickly and started me down the path that lead to the simple stand alone project you suggested. I appreciate the level of support, especially given the amazingly low subscription fee. (I almost said “absurdly low” but I wouldn’t want to encourage you to raise your prices 😉

[Author]

Posts