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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
