ср, 19 сент. 2018 г. в 22:20, Berneburg, Cris J. - US <cberneb...@caci.com>: > > Hi Folks > > We can't figure out what's wrong with our staging server. After upgrading > Java and our application, Tomcat started logging "Compilation error" > exceptions. The login JSP page did not display. > > After reverting Java and our app, the app still won't run and still throws > compilation errors. Tomcat is working because we can access the Manager and > Host Manager applications. > > As for the app deployment, we: > 1. Stop the Tomcat service. > 2. Delete the contents of the tomcat folder > work/Catalina/localhost/app/org/apache/jsp. > 3. Delete the contents of the app folder under webapps. > 4. Copy the new app exploded structure to the webapps app folder. > 5. Reboot the server (Windows Server 2012). > > * Staging Server - before upgrade > JRE 8u171, 32 bit > Tomcat 6.0.32, 32 bit > App v3.3.2 > > * Staging Server - after upgrade > JRE 8u181, 32 bit > Tomcat 6.0.32, 32 bit (unchanged) > App v3.4.1 > > * Staging Server - after rollback > JRE 8u171, 32 bit > Tomcat 6.0.32, 32 bit (unchanged) > App v3.3.2 > > * Production Server > JRE 8u171, 32 bit > Tomcat 6.0.32, 32 bit > App v3.3.2 > > * Test Server > JRE 8u181, 64 bit > Tomcat 6.0.37, 64 bit > App v3.4.1 > App v3.3.2 > > * Dev/Build Server > JDK 8u181, 64 bit > Tomcat 6.0.37, 64 bit > App v3.4.1 > App v3.3.2 > > * Also: > a. The 32-bit staging versus 64-bit app build was not an issue in production. > b. The Tomcat revision 32 in staging versus 37 in dev/test has not been an > issue in prod. > c. This deployment method has worked for years. > d. I don't think the staging server needs either the JAVA_HOME or > CATALINA_HOME environment variables because production does not have them > either. > e. The Tomcat service uses the built-in system account. > > * Partial stack trace: > org.apache.jasper.compiler.JDTCompiler$1 findType > SEVERE: Compilation error > org.eclipse.jdt.internal.compiler.classfmt.classFormatException > at > org.eclipse.jdt.internal.compiler.classfmtClassFileReader.<init>(ClassFileReader.java:342) > at org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:206) > at org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:163) > at > org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:96) > at > org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49) > at > org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:97) > at > org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:167) > at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2187) > at > org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:974) > at > org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1164) > at > org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:366) > at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:623) > [...] > > Got any ideas? Your help would be appreciated. Thanks!
My guess is that the Eclipse Compiler for Java in your Tomcat 6.0.32 was released N years ago and cannot deal with Java 8u181. From the message it looks like it cannot parse some class file. 1. Replacing ecj-n.n.n.jar in your copy of Tomcat with a more recent version (from a later version of Tomcat, or directly from Eclipse.org) may work. At least as a temporary solution. Their API is compatible and the main reason why newer library is not shipped with old versions of Tomcat is because it requires Java 8 to run (and Tomcat 6.0 must be able to run on Java 5). Option 2: Upgrade!! Tomcat 6 has reached end of life. See https://tomcat.apache.org/security-6.html https://tomcat.apache.org/tomcat-60-eol.html https://tomcat.apache.org/migration.html Option 3: Switch to using a javac compiler from JDK instead of ECJ compiler. It is possible via configuration, but YMMV. It is a rarely used option. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
