On September 20, 2018 3:05:00 PM UTC, "Berneburg, Cris J. - US" <cberneb...@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-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org
Stop Tomcat. Empty the work directory. Start Tomcat. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
