Classloader issues

[Gary L Peskin <ga...@firstech.com>]

I think that the time has come to decide how XalanJ should deal with
various classloader issues.  ClassLoader problems are becoming more
prevalent as XalanJ is being deployed in various environments.  In
addition to the regular old java application, we now have to deal with
its use in servlets, EJBs, and various development tools like WSAD.
Many of these containers do interesting things with ClassLoaders and
seem to give rise to a lot of questions on the user list.  This is
complicated by the fact that virtually every release of Tomcat, for
example, has a different classloader strategy.  IBM's WAS is constantly
changing classloader strategies and now supports five separate
strategies, called classloader "modes".  In addition to having so many
modes, one of the modes, Module mode, acts differently depending whether
you're on WebSphere 4.0.2 or 4.0.3, for example!

In order to ease the support burden and make XalanJ more usable from
these various environments, I think that we need to improve
documentation of how XalanJ uses classloaders.  This gives rise to the
question as to how we actually do use the classloaders and how we should
use the classloaders.  Once we've agreed upon a strategy, we can go
about incorporating this strategy into XalanJ, vastly improving our
error messages (by including the classloader hierarchy that we used,
where appropriate), and documenting how to set up XalanJ for various
environments.

I've done a brief look through the code to find out where we're loading
things and I've come up with the following three categories.  I think
that we should agree on the categories first and then talk about how to
deal with each category.  I'll leave that to a separate email since it
gets kind of detailed.  Please note that some of items that we load are
specified by JAXP or other standards so we cannot really change that on
our own.

The categories that I've come up with are:

1.  Extension classes.  These are java (and non-java) classes that are
loaded as part of the extension mechanism.  This includes user-written
extensions as well as extensions supplied with XalanJ.

2.  "Properties" files.  This includes files containing java properties
or "property-like" information.  Two of the issues for loading these
properties files are:
  a.  Which classloader to use
  b.  Should we use the fully qualified object name, including the
package or should we omit the package name and just pick it up from the
classpath and the package of the loading class or no package name or try
these in some specified order or what?
The files that I've found are through my quick review are:

  org.apache.xalan.res.XSLTInfo.properties
    Contains system properties set by the Transformer when it cranks up.

  org.apache.xalan.serialize.HTMLEntities.res
  org.apache.xalan.serialize.XMLEntities.res
    Loaded by the serializers to determine what unicode values should be
entity-ized.

  org.apache.xalan.serialize.Encodings.properties
    Shows correspondence between MIME names and java encoding names.

  META-INF/services/org.apache.xml.dtm.DTMManager
  META-INF/services/javax.xml.transform.TransformerFactory
    Note that these files are not really in packages.  The part after
"services/" is actually a file name.
    These files actually specify a class that is dynamically loaded at
run time (see category 3, below).  Note that the issue of how to find
these files is separate from the issue of how to find the classes whose
names appear in these files.

  org.apache.xalan.templates.output_html.properties
  org.apache.xalan.templates.output_text.properties
  org.apahce.xalan.templates.output_xml.properties
    These contain default OutputProperties for use in the
OutputProperties constructor and by others who want to create their own
output properties

  org.apache.xpath.res.XPATHErrorResources.properties
  org.apache.xalan.res.XSLTErrorResources.properties
    These contain error message resources, to promote i18n.

3.  Classes "dynamically" loaded by XalanJ.  These include:
(1) the classes specified in the META-INF/services files, 
(2) additional files loaded by XalanJ which include things like
sun.io.CharToByteConverter (used in Encodings.java)
(3) the class specified in OutputProperties with property name
"{http\u003a//xml.apache.org/xslt}content-handler"
(this is arguably an extension class, falling under category 1. above).
(4) the class to be pooled in an ObjectPool
(5) internal Xerces classes used in IncrementalSaxSource_Xerces:
      org.apache.xerces.xni.parser.XMLParserConfigurator
      org.apache.xerces.parsers.StandardParserConfiguration
      org.apache.xerces.xni.parser.XMLInputSource.

I'd appreciate any feedback or input that anyone has as we start down
this road.  Suggested standards for each category, or refinements of the
categories or anything else.

Thanks,
Gary

Re: Classloader issues

[Edwin Goei <ed...@sun.com>]

Gary L Peskin wrote:
> 
> I'd appreciate any feedback or input that anyone has as we start down
> this road.  Suggested standards for each category, or refinements of the
> categories or anything else.

Yes, I agree that something needs to be done in this area.  (I was just 
discussing this issue.)  I think the immediate need is to get some 
debugging information so users can figure out what went wrong.  In some 
versions of javax.xml.{parsers,transform}.FactoryFinder, there is code 
that will show where the JAXP SPI implementation (impl) gets loaded 
from, for example.  In addition, there needs to be a good way to 
identify the version of the impl.  I know there is one API that is 
Apache specific, but this API should probably be part of JAXP.  One way 
is to use the Java 2 java.lang.Package, but this requires jar files to 
include manifests which is not often done.  I think something like this 
needs to be added to the next JAXP spec so that a TCK will be written to 
verify its implementation.

However, what you are writing about is more broad than what I just 
covered and a more challenging problem.

-Edwin

PS: Thanks Gary for cc-ing me.