Jetty has moved!
Jetty is a project at the Eclipse Foundation.
Homepage:http://www.eclipse.org/jetty
Downloads: http://download.eclipse.org/jetty/
Documentation:http://www.eclipse.org/jetty/documentation/current/
About:http://www.eclipse.org/jetty/about.php
Jetty Powered:http://www.eclipse.org/jetty/powered/
Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery
Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 4 Next »

What is Jetty's classloading architecture?

Class loading in a web container is slightly more complex than a normal java application.

The normal configuration is for each web context (web application or war file) is given it's own classloader, which has the system classloader as it's parent. Such a classloader hierarchy is normal in Java, however the servlet specification complicates the hierarchy by requiring that:

  • Classes contained within WEB-INF/lib or WEB-INF/classes have priority over classes on the parent class loader. This is the opposite of the normal behaviour of a java 2 class loader.
  • System classes such as java.lang.String may not be replaced by classes in WEB-INF/lib< or WEB-INF/classes. Unfortunately the specification does not clearly state what classes are "System" classes and it is unclear if all javax classes should be treated as System classes.
  • Server implementation classes should be hidden from the web application and should not be available in any class loader. Unfortunately the specification does not state what is a Server class and it is unclear if common libraries like the xerces parser should be treated as Implementation classes.

How to configure classloading

Jetty provides configuration options to control all three of these options. The method org.mortbay.jetty.webapp.WebAppContext.setParentLoaderPriority(boolean) allows the normal java 2 behaviour to be used and all classes will be loaded from the system classpath if possible. This is very useful if the libraries that a web application uses are having problems loading classes that are both in a web application and on the system classpath.

The methods org.mortbay.jetty.webapp.WebAppContext.setSystemClasses(String[]) and org.mortbay.jetty.webapp.WebAppContext.setServerClasses(String[]) may be called to allow fine control over what classes can be seen or overridden by a web application.

  • SystemClasses cannot be overriden by webapp context classloaders. The defaults are; {"java.","javax.servlet.","javax.xml.","org.mortbay.","org.xml.","org.w3c."}
  • ServerClasses cannot be seen by webapp context classloaders. The defaults are: { "-org.mortbay.naming.","-org.mortbay.util.","org.mortbay.", "org.slf4j."};

Absolute classname can be passed, names ending with . are treated as packages names and names starting with - are treated as negative matches and must be listed before any enclosing packages.

Adding extra classpaths to Jetty

At startup, the jetty runtime will automatically load all jars from the top level $jetty.home/lib, along with certain subdirectories such as $jetty.home/lib/management/, $jetty.home/lib/naming/ etc, which are named explicity in the start.config file contained in the start.jar. In addition, it will recursively load all jars from $jetty.home/lib/ext. So, to add extra jars to jetty, you can simply create a file hierarchy as deep as you wish within $jetty.home/lib/ext to contain these jars. Of course, you can always change this default behaviour by creating your own start.config file and using that instead.

If you want to add a couple of class directories or jars to jetty, but you can't put them in $jetty.home/lib/ext/ for some reason, or you don't want to create a custom start.config file, you can simply use the System property -Djetty.class.path on the runline instead. Here's how it would look:

  • No labels
Contact the core Jetty developers at www.webtide.com
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery