Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

Version 1 Next »

Whenever you save a Java source file, Eclipse compiles the source and stores the generated *.class file. The Eclipse project structure is able to test a J2EE application like CAS without ever actually building all the JAR artifacts.

Examine the cas-server-webapp project. You will notice that it has an unusual structure with additional items:
When the Eclipse Maven plugin [with the J2EE Maven plugin optional extension] created this project, it noticed that the POM declared that this was a WAR artifact. So it build an Eclipse J2EE WAR project, which has this special structure.

During project creation, the Dependencies in the POM were examined and they were divided into two groups. The ordinary library JAR artifacts were put in the Maven Dependencies list while dependencies on prior projects are broken out separately. You can see this by right clicking on the WAR project and selecting Build Path - Configure Build Path - Libraries
This example reflects the vanilla cas-server-webapp project distributed by JA-SIG where the only one of the optional projects that actually gets included in the war is the required cas-server-core. However, if you select other optional projects to include in the configuration and add them to the POM, they will also be added to the Build Path "Web App Libraries".

What happens next depends on the particular Application Server you want to test under and the particular plugin that you use to do the testing. There are two strategies.

The Eclipse Web Tools project has a particular debugging style that works well with Tomcat. You configure the Windows - Preferences - Server - Runtime Environments to point to an instance of Tomcat. That provides a copy of the base code. However, the Eclipse J2EE support knows that you can start Tomcat with a special parameter to insert your own ClassLoader implementation. Instead of copying all the class files into Tomcat, or zipping them up to build JAR and WAR files as a normal production installation would do, Eclipse simply inserts a substitute ClassLoader into Tomcat that knows where to go in the Eclipse workspace to get the class files generated by the projects listed in the Web App Libraries list (in this case, the cas-server-core output directory and the WEB-INF/classes of the webapp directory. Whenever Tomcat needs classes, then at the point where it would normally search the WAR directory, it instead obtains them from the Web App Libraries configured in the Build Path for the WAR project. That is, Tomcat get its classes directly from the Eclipse workspace without having to copy them over to some Tomcat directory.

However, this is not the only available strategy. When the ClassLoader trick will not work, or when it is desirable to copy all the class files and the webapp files into the normal deploy directory of the J2EE server, Eclipse can do that too. Then the server is started as it normally would be from its normal directories, except that it runs in debug mode.

If you are frequently editing and changing source, the Eclipse approach is faster and simpler than the Maven build, but only slightly so.

  • No labels