tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: help with org.apache.jasper.compiler.JDTCompiler issue?
Date Thu, 20 Sep 2018 15:29:19 GMT
On September 20, 2018 3:05:00 PM UTC, "Berneburg, Cris J. - US" <cberneburg@caci.com>
wrote:
>Konstantin
>
>Thanks for jumping in to help out.  :-)
>
>cjb> After reverting Java and our app, the app still
>cjb> won't run and still throws compilation errors.
>
>cjb> * Staging Server - after rollback
>cjb> JRE 8u171, 32 bit
>cjb> Tomcat 6.0.32, 32 bit (unchanged)
>cjb> App v3.3.2
>
>kk> My guess is that the Eclipse Compiler for Java in
>kk> your Tomcat 6.0.32 was released N years ago and
>kk> cannot deal with Java 8u181. From the message it
>kk> looks like it cannot parse some class file.
>
>Except that we reverted both Java and our application back to the
>previous versions, 8u171 and 3.3.2 respectively, and still get the
>error.
>
>cjb> * Partial stack trace:
>cjb> org.apache.jasper.compiler.JDTCompiler$1 findType
>cjb> SEVERE: Compilation error
>cjb> org.eclipse.jdt.internal.compiler.classfmt.classFormatException
>cjb> at
>org.eclipse.jdt.internal.compiler.classfmtClassFileReader.<init>(ClassFileReader.java:342)
>cjb> at
>org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:206)
>cjb> at
>org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:163)
>cjb> at
>org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:96)
>cjb> at
>org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
>cjb> at
>org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:97)
>cjb> at
>org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:167)
>cjb> at
>org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2187)
>cjb> at
>org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:974)
>cjb> at
>org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1164)
>cjb> at
>org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:366)
>cjb> at
>org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:623)
>cjb> [...]
>
>Is it possible that something on the server changed while the older app
>was running, but the effects of the change were not revealed until
>after the reboot?  That is, maybe everything was resident and running
>in memory, but something on the disk changed while the old version was
>still in use, so the old version was broken on disk before we even
>started doing upgrades.  In effect, the rug got pulled out from
>underneath the app, but TC or the app didn't notice until after the new
>app was reloaded into memory.  Is that possible?
>
>kk> Option 2: Upgrade!!
>kk> Tomcat 6 has reached end of life.
>
>I knew someone would say that.  :-)  Yeah, that's "next" down the road,
>once this round of upgrades is done.
>
>kk> Option 3: Switch to using a javac compiler from JDK instead of ECJ
>compiler.
>kk> It is possible via configuration, but YMMV. It is a rarely used
>option.
>
>Huh, I was wondering about the built-in compiler.  Rather than do
>something non-standard, I'd like to employ a simple solution.
>
>--
>Cris Berneburg
>CACI Lead Software Engineer
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org

Stop Tomcat. Empty the work directory. Start Tomcat.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message