Everything had been working fine on Eclipse Kepler + Java 1.6. As I was building a new local environment, I decided to upgrade my Eclipse at the same time.

I downloaded the latest Eclipse version, Mars. It requires a minimum Java level of 1.7 to run. Our code is only tested on Java 1.6. So I planned to run Eclipse on the latest Java version, 1.8, while running our code on 1.6. I set the compiler compatibility level to 1.6.

First there was the Git issue as mentioned in the prior post.

Then when I tried building the code, strange things happened. First there were memory / heap space errors, and crashes. After finding the right Java memory settings to avoid those issues, the build no longer crashed, nor did it complete. It went on and on... and periodically popped up tons of windows all with the same message, while doing so. It seemed stuck in a loop.

Rather than switching to Java 1.7 and risking still having the same problem, I decided to try Eclipse Luna + Java 1.6. At least that would be a partial upgrade. (I vaguely recall a coworker having a different compile issue with Kepler + 1.7, so it's probably good I didn't try 1.7.)

Everything seemed fine with Luna. The builds worked, and the code ran ok.

Then I wanted to debug one of our other projects which uses Maven. But the File - Import menu and the Preferences window were missing the Maven entries, even though Eclipse showed Maven as being installed.

It seemed like my Eclipse might be corrupted, so I downloaded a fresh copy. With the fresh copy, the Maven entries were there! Then I installed the Spring Tool Suite in the fresh workspace, as the other projects require Spring. But after the install, the Spring entries were missing from the menus and Preferences window! Even though they had been present in the first workspace!

Now I had one workspace with the Maven entries present and the Spring ones missing, and another workspace with the Spring entries present but the Maven ones missing.

It finally occurred to me to check the Eclipse .log files in both workspaces. Both .log files showed startup errors related to the m2e and Spring components requiring at least Java 1.7. (Don't ask me why Spring seemed to be working ok in the 1st workspace but not the 2nd.)

So, after all that, I'm going back to using Kepler. There's a team tasked with doing a technology upgrade project, so hopefully they'll get our code compatible with the latest Java and then I'll be able to upgrade Eclipse.
According to the Tomcat Class Loader How-To page, Tomcat has 4 class loaders.

The Bootstrap class loader loads Java stuff.
The System class loader, when using the Tomcat startup scripts, loads a few jars from the Tomcat bin folders.
The Common class loader loads jars from the Tomcat lib folders.
The WebappX class loader loads jars from the application's WEB-INF/classes and lib folders.

My application's open-source jars are all maintained in a few special folders. For testing the application, I want Tomcat to load the jars from those folders, to avoid having to copy all the jars into the WEB-INF/lib folder. (I don't want to build and deploy a WAR file just for testing).

So, I'm using a "setenv.bat" file in the CATALINA_BASE/bin folder, with a SET CLASSPATH statement to load the jars from the open-source folders.

I start Tomcat with the startup.bat file (on Windows). It works. But only when I also include Tomcat\bin\tomcat-juli.jar and Tomcat\lib\servlet-api.jar in the SET CLASSPATH statement. Otherwise Tomcat gets startup errors.

I understand why tomcat-juli.jar needs to be included even though the System class loader is supposed to load it. My open-source jars include a different version of the juli jar, which is not the one Tomcat needs. When the open-source juli jar is in the WEB-INF\lib folder, the Tomcat\bin version takes precedence. However, when it is in the SET CLASSPATH statement in setenv.bat, it gets loaded first unless you list the other jar first.

The mystery (to me), is why do I need to include servlet-api.jar in the SET CLASSPATH statement? My open source folders (as far as I can tell) don't have any other version of that jar. When I don't include the jar in the statement, I get a ClassNotFound error on javax.servlet.ServletContainerInitializer.

According to the Tomcat documentation, servlet-api.jar is supposed to be loaded by the Common class loader. So why doesn't that happen?

Is the Common class loader not used, when starting Tomcat via the startup scripts?

Process Explorer seems to show that the Tomcat\lib\ jars are all loaded - they are listed in the Java process' "Files" section.
JarFish is a useful tool for dealing with Java classpath issues.

It lets you search all the jar files under a specific folder to find a given class.
Example: java -jar jarfish-1.0-rc7.jar find ClassBeingSearchedFor C:\projectFolder\lib

The package name prefixes (such as com.abc.) do not need to be included in the class name that you list in the command, but the class name is case sensitive.

It also lets you search all the jar files under a specific folder to find any classes which exist in more than one jar file.
Example: java -jar jarfish-1.0-rc7.jar dupes C:\projectFolder\lib



September 2017

     1 2


RSS Atom

Most Popular Tags

Active Entries

Style Credit

Expand Cut Tags

No cut tags