tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Winch <>
Subject Re: "VerifyError: ... Illegal constant pool index" when jspx invokes a tagx on Tomcat 7.0.16
Date Thu, 08 Dec 2011 14:19:12 GMT
On Thu, Dec 8, 2011 at 4:29 AM, Pid <> wrote:

> On 07/12/2011 17:32, Robert Winch wrote:
> > 3) I have looked for any jars included in the war that might contain the
> > wrong JspTag or PageContext. I tried to do an open type in Eclipse on
> both
> > classes and found jsp-api and servlet-api both contain these classes.
> You are saying your servlet-api.jar contains the JSP API classes too?
> I would be concerned about two versions of a class being in the same
> classloader - but you say below that they are not packaged in the WAR.

Despite the jars not being included in the war I thought this was a point
worth investigating. I need to apologise for providing a bit of
misinformation. The servlet-api-2.3, which had the duplicate classes, was
actually part of another project within my Eclipse workspace. Looking more
closely these classes are not duplicated in the project that had the
VerifyError since it had a different servlet-api jar on its classpath. I
also reconfirmed that neither jars are not packaged in the war's
WEB-INF/lib directory.

> Can you upgrade to 7.0.21?  There have been a few beneficial changes to
> the JSP components.

That is good information to know. We plan on updating to 7.0.23 within the
next few weeks.

> You say below that the compiled tags & JSP don't appear to have been
> recompiled - either upgrade, or clear the work directory to ensure that
> they have been.

I'm not sure I understand. Is there a reason we would want them to be
recompiled? The reason I had mentioned this was not because I thought it
was a problem but because I thought it helped rule out a problem with how
the jsp's were compiled. I'm not certain if my logic is sound, but I
thought since it was not working, later did work, and the time stamp had
not been updated there was likely something other than the compilation of
the jsp's at fault.

> p

Thanks for your response,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message