Message-ID: <718408748.2101.1369279685769.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2100_1883547025.1369279685768" ------=_Part_2100_1883547025.1369279685768 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
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 i= t's parent. Such a classloader hierarchy is normal in Java, however the ser= vlet specification complicates the hierarchy by requiring that:
WEB-INF/c= lasseshave priority over classes on the parent class loader. This = is the opposite of the normal behaviour of a java 2 class loader.
WEB-INF/classes. Unfortunat= ely the specification does not clearly state what classes are "System&= quot; classes and it is unclear if all javax classes should be treated as S= ystem classes.
Jetty provides configuration options to control all three of these optio=
ns. The method
Priority(boolean) allows the normal java 2 behaviour to be used and =
all classes will be loaded from the system classpath if possible. This is v=
ery 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 class=
erClasses(String) may be called to allow fine control over what cl=
asses can be seen or overridden by a web application.
Absolute classname can be passed, names ending with . are treated as pac= kages names and names starting with - are treated as negative matches and m= ust be listed before any enclosing packages.
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 explici= ty in the star= t.config file contained in the start.jar. In addition, it will recursiv= ely 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.h= ome/lib/ext to contain these jars. Of course, you can always change this de= fault behaviour by creating your own start.config file and using that instead. Otherw= ise, you can use one of the methods below.
If you want to add a couple of class directories or jars to jetty, but y=
ou can't put them in $jetty.home/lib/ext/ for some reason, or you don't wan=
t to create a custom start.config file, you can simply use the System prope=
-Djetty.class.path on the runline instead. Here's how it w=
If you need to add some jars or classes that for some reason are not in = $jetty.home/lib nor inside your webapp's WEB-INF/lib or WEB-INF/classes, yo= u can add them directly to your webapp in a $JETTY_HOME/contexts/mycontext= .xml file:
Finally, if none of the other alternatives already described meet your n= eeds, you can always provide a custom classloader for your webapp. It is re= commended, but not required, that your custom loader subclasses org.mortbay.jetty.webapp.We= bAppClassLoader. You configure the classloader for the webapp like so:<= /p>------=_Part_2100_1883547025.1369279685768--