Jetty class loading

Ssloader, the system classloader as its father. In Java, this hierarchical relationship is normal, but the servlet specification complicate the hierarchical relationship because it requires:
1) classes contained in the WEB-INF/lib or WEB-INF/classes take precedence over classes on the parent classloader. This is opposite to the usual Java 2 classloader behavior.
2) system classes such as Java. Lang. String are excluded from webapp priority and you cannot replace them with classes in WEB-INF/lib or WEB-INF/classes. Unfortunately, the specification does not clearly state what classes are system classes, and whether all javax classes should be treated as system classes.
3) The server implementation class image server should be hidden from web applications and should not be available in any classloader. Unfortunately, the specification does not state what classes are server classes, and whether public libraries like the xerces parser should be treated as implementation classes.

Configure webapp classloading

Jetty provides configuration options to control the loading of the three webapp classes listed above.
You can configure webapp classloader through several methods on webappcontext. You can call these methods directly, or you can configure them through the context XML file. You cannot set these methods from the jetty-web.xml because it will be executed after the classloader configuration is set.

Control the priority of webapp classloader

Method org. Eclipse. Jetty. webapp. webappcontext. setparentloaderpriority (Boolean) allows you to control the priority. If you set it to false (default), Jetty uses the standard webapp class to load the priority. However, in this mode, if some classes dependent on other classes are loaded by the parent loader (due to the following system class settings ), ambiguity can occur in that both webapp and system classloader versions can end loading.
If it is set to true, Jetty uses the normal javase class to load the priority and gives the priority to the parent/system classloader. This avoids the multi-version issue of a class in a webapp, but the version provided by the parent/system loader must be the correct version for all webapps.

Set the system class

You can call the org. eclipse. jetty. webapp. webappcontext. setsystemclasses (String Array) or Org. eclipse. jetty. webapp. webappcontext. addsystemclass (string) is used to control which classes are system classes.
1) a web application can see a system class;
2) A WEB-INF class cannot replace a system class.
Default System classes include:

Java.
Java SE classes (per servlet spec v2.5/srv.9.7.2 ).

Javax.
Java SE classes (per servlet spec v2.5/srv.9.7.2 ).

Org. xml.
Required by javax. xml.

Org. W3C.
Required by javax. xml.

Org. Eclipse. Jetty. continuation.
Webapp can see but cannot change the continuation class.

Org. Eclipse. Jetty. JNDI.
Webapp can see but cannot change the naming class.

Org. Eclipse. Jetty. JAAS.
Webapp can see but cannot change the JAAS class.

Org. Eclipse. Jetty. websocket.
Websocket is a jetty extension.

Org. Eclipse. Jetty. servlet. DefaultServlet
Webapp can see but cannot change the default servlet.

The absolute class name is legal, and the name ends with "." As the package name. The name starts with "-" as a negative match and must be listed before any closed package.

Set server class

You can call the org. eclipse. jetty. webapp. webappcontext. setserverclasses (String Array) or Org. eclipse. jetty. webapp. webappcontext. addserverclass (string) controls which class is a server class.
1) The web application cannot see the server class;
2) WEB-INF class can replace server class.
Default Server classes include:

-Org. Eclipse. Jetty. continuation.
The continuation class is not hidden.

-Org. Eclipse. Jetty. JNDI.
Do not hide the naming class.

-Org. Eclipse. Jetty. JAAS.
Do not hide the JAAS class.

-Org. Eclipse. Jetty. servlets.
Do not hide the servlet class. If yes.

-Org. Eclipse. Jetty. servlet.
The default servlet class is not hidden.
 
-Org. Eclipse. Jetty. servlet. listener.
Do not hide listeners

-Org. Eclipse. Jetty. websocket.
Do not hide websocket extensions

Org. Eclipse. Jetty. do hide all other jetty classes.
Hide all other jetty classes.

Add additional class paths to Jetty

You can add additional class paths to jetty in the following ways:

Use start. Jar

If you are using start. jar, the optional jar is automatically loaded from the top $ Jetty. Home/lib folder when Jetty is running. The default settings include:
1) Add the JAR file to the system class path under $ Jetty. Home/lib/Ext. You can place the attached jar here.
2) Add the folder $ Jetty. Home/resources to the class path (including the class path or other resources ).
3) use the command line parameter path to add a single path definition.

Use the extraclasspath () method

You can add an additional class path to a context classloader and call org. Eclipse. Jetty. webapp. webappcontext. setextraclasspath (string) by using a comma-separated path list ). You can use the context XML file as follows;

<Configure class="org.eclipse.jetty.webapp.WebAppContext"> ... <Set name="extraClasspath>../my/classes,../my/jars/special.jar,../my/jars/other.jar> </Set> ...

Use custom webapp classloader

If none of the above methods meet your needs, you can provide a custom classloader for your webapp. We recommend that you do not require that your custom loader inherit from webappclassloader. You configure classloader for your application as follows:

MyCleverClassLoader myCleverClassLoader = new MyCleverClassLoader(); ...   WebAppContext webapp = new WebAppContext(); ...   webapp.setClassLoader(myCleverClassLoader);

You can also complete the configuration in a context XML file.

Start jetty With custom classloader

If you use a custom classloader to start the jetty server, consider that the jetty class is not available for the system class loader and is only available for your custom Class Loader. When the webappclassloader enters, you may encounter class loading problems. Webappclassloader uses the system class loader as his father by default, so there is a problem. This is easy to fix, using the following method:

context.setClassLoader(new WebAppClassLoader(this.getClass().getClassLoader(), context));

Or

context.setClassLoader(new WebAppClassLoader(new MyCustomClassLoader(), context));