public class LibExtClassLoaderHelper extends Object
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 JettyBootstrapActivator 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
JettyBootstrapActivator 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
Modifier and Type | Class and Description |
---|---|
static interface |
LibExtClassLoaderHelper.IFilesInJettyHomeResourcesProcessor
Class called back
|
Modifier and Type | Field and Description |
---|---|
static Set<LibExtClassLoaderHelper.IFilesInJettyHomeResourcesProcessor> |
registeredFilesInJettyHomeResourcesProcessors |
Constructor and Description |
---|
LibExtClassLoaderHelper() |
Modifier and Type | Method and Description |
---|---|
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.
|
public static Set<LibExtClassLoaderHelper.IFilesInJettyHomeResourcesProcessor> registeredFilesInJettyHomeResourcesProcessors
public static ClassLoader createLibEtcClassLoader(File jettyHome, Server server, ClassLoader parentClassLoader) throws MalformedURLException
server
- MalformedURLException
public static ClassLoader createLibExtClassLoader(List<File> jarsContainerOrJars, List<URL> otherJarsOrFolder, Server server, ClassLoader parentClassLoader) throws MalformedURLException
server
- MalformedURLException
protected static void processFilesInResourcesFolder(File jettyHome, Map<String,File> childrenFiles)
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-2015 Mort Bay Consulting. All Rights Reserved.