org.eclipse.jetty.osgi.boot.internal.webapp
Class LibExtClassLoaderHelper

java.lang.Object
  extended by org.eclipse.jetty.osgi.boot.internal.webapp.LibExtClassLoaderHelper

public class LibExtClassLoaderHelper
extends Object

Helper to create a URL class-loader with the jars inside ${jetty.home}/lib/ext and ${jetty.home}/resources. In an ideal world, every library is an OSGi bundle that does loads nicely. To support standard jars or bundles that cannot be loaded in the current OSGi environment, we support inserting the jars in the usual jetty/lib/ext folders in the proper classpath for the webapps.

Also the folder resources typically contains central configuration files for things like: log config and others. We enable fragments to register classes that are called back and passed those resources to do what they need to do.

For example the test-jndi webapplication depends on derby, derbytools, atomikos none of them are osgi bundles. we can either re-package them or we can place them in the usual lib/ext.
In fact jasper's jsp libraries should maybe place in lib/ext too.

The drawback is that those libraries will not be available in the OSGi classloader. Note that we could have setup those jars as embedded jars of the current bundle. However, we would need to know in advance what are those jars which was not acceptable. Also having those jars in a URLClassLoader seem to be required for some cases. For example jaspers' TldLocationsCache (replaced by TldScanner for servlet-3.0).
Also all the dependencies of those libraries must be resolvable directly from the JettyBooStrapper bundle as it is set as the parent classloader. For example: if atomikos is placed in lib/ext it will work if and only if JettyBootStrapper import the necessary packages from javax.naming*, javax.transaction*, javax.mail* etc Most of the common cases of javax are added as optional import packages into jetty bootstrapper plugin. When there are not covered: please make a request or create a fragment or register a bundle with a buddy-policy onto the jetty bootstrapper..

Alternatives to placing jars in lib/ext

  1. Bundle the jars in an osgi bundle. Have the webapp(s) that context depends on them depend on that bundle. Things will go well for jetty.
  2. Bundle those jars in an osgi bundle-fragment that targets the jetty-bootstrap bundle
  3. Use equinox Buddy-Policy: register a buddy of the jetty bootstrapper bundle. (least favorite: it will work only on equinox)


Nested Class Summary
static interface LibExtClassLoaderHelper.IFilesInJettyHomeResourcesProcessor
          Class called back
 
Field Summary
static Set<LibExtClassLoaderHelper.IFilesInJettyHomeResourcesProcessor> registeredFilesInJettyHomeResourcesProcessors
           
 
Constructor Summary
LibExtClassLoaderHelper()
           
 
Method Summary
static ClassLoader createLibEtcClassLoader(File jettyHome, Server server, ClassLoader parentClassLoader)
           
static ClassLoader createLibExtClassLoader(List<File> jarsContainerOrJars, List<URL> otherJarsOrFolder, Server server, ClassLoader parentClassLoader)
           
protected static void processFilesInResourcesFolder(File jettyHome, Map<String,File> childrenFiles)
          When we find files typically used for central logging configuration we do what it takes in this method to do what the user expects.
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Field Detail

registeredFilesInJettyHomeResourcesProcessors

public static Set<LibExtClassLoaderHelper.IFilesInJettyHomeResourcesProcessor> registeredFilesInJettyHomeResourcesProcessors
Constructor Detail

LibExtClassLoaderHelper

public LibExtClassLoaderHelper()
Method Detail

createLibEtcClassLoader

public static ClassLoader createLibEtcClassLoader(File jettyHome,
                                                  Server server,
                                                  ClassLoader parentClassLoader)
                                           throws MalformedURLException
Parameters:
server -
Returns:
a url classloader with the jars of resources, lib/ext and the jars passed in the other argument. The parent classloader usually is the JettyBootStrapper (an osgi classloader.
Throws:
MalformedURLException

createLibExtClassLoader

public static ClassLoader createLibExtClassLoader(List<File> jarsContainerOrJars,
                                                  List<URL> otherJarsOrFolder,
                                                  Server server,
                                                  ClassLoader parentClassLoader)
                                           throws MalformedURLException
Parameters:
server -
Returns:
a url classloader with the jars of resources, lib/ext and the jars passed in the other argument. The parent classloader usually is the JettyBootStrapper (an osgi classloader). If there was no extra jars to insert, then just return the parentClassLoader.
Throws:
MalformedURLException

processFilesInResourcesFolder

protected static void processFilesInResourcesFolder(File jettyHome,
                                                    Map<String,File> childrenFiles)
When we find files typically used for central logging configuration we do what it takes in this method to do what the user expects. Without depending too much directly on a particular logging framework.

We can afford to do some implementation specific code for a logging framework only in a fragment.
Trying to configure log4j and logback in here.

We recommend that slf4j jars are all placed in the osgi framework. And a single implementation if possible packaged as an osgi bundle is there.



Copyright © 1995-2011 Mort Bay Consulting. All Rights Reserved.