tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berneburg, Cris J. - US" <cberneb...@caci.com>
Subject Re: help with org.apache.jasper.compiler.JDTCompiler issue?
Date Thu, 20 Sep 2018 15:05:00 GMT
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


Mime
View raw message