[PATCH] TC4: TomcatBlock on Avalon 3.1a1: Part 2 (for real this time)

[Jason Brittain <ja...@olliance.com>]

Last time I forgot to attach the diffs!  Sorry..  This mail has them.


Attached are the diffs to the files that I modified to make TomcatBlock
(Tomcat 4 running on Avalon 3.1a1).


Explanation:


build.xml (the top-level build.xml file)

I moved the dist-opt-avalon target (and associated stuff) to this file
since to build the bar file it needs to copy stuff from Catalina,
Jasper, and webapps.


catalina/build.xml

Removed the dist-opt-avalon target from this file, added some more
lines about only compiling Avalon-dependent source if Avalon is
present.


catalina/src/share/org/apache/catalina/core/ContainerBase.java

I needed to fix an obscure bug in this file to get AvalonFileLogger to
work.  What was happening was: When one of the class loaders starts
up, it tries to log some things in some cases.  But, its logger has
not yet been started yet, so the class loader ends up throwing an
exception (can't remember what kind).  To fix this, I switched the
startup order: the loader's logger gets started first, then the loader
that uses it gets started.  I'm not real sure how this could have
worked properly before this patch.  :)


catalina/src/share/org/apache/catalina/startup/Bootstrap.java

This one's the tough one!

I had a hard time getting Jasper to work inside the TomcatBlock, even
after the block deployed all of the usual directories to the
filesystem.  This is because Jasper needs the JDK's tools.jar on its
classpath.  When you run Catalina from the command line (stand-alone),
the startup script catalina.sh puts tools.jar on the classpath:

  if [ -f "$JAVA_HOME/lib/tools.jar" ] ; then
    CP=$CP:"$JAVA_HOME/lib/tools.jar"
  fi

But, when starting from Avalon, you don't have the shell script to add
it to the classpath for you.  So, I figured all I needed to do was
have TomcatBlock create its own ClassLoader that adds tools.jar (and
maybe some other jars too) and start up the Bootstrap class just like
CatalinaBlock did, but load it from the ClassLoader that TomcatBlock
created.

So, I tried that.  It didn't work.  After tearing out some hair, I
found the problem.  Bootstrap's createCommonLoader() method creates a
new StandardClassLoader with a set of URLs (an array of them) like
this:

  StandardClassLoader loader = new StandardClassLoader(array);

This constructor of StandardClassLoader makes a new
StandardClassLoader with the array of URLs (to jars or other paths)
setting the default parent class loader as its parent, instead of
setting Bootstrap's ClassLoader as its parent.  This caused Jasper to
not use the class loader I created to give it access to tools.jar,
thus making Jasper not work.

Now, if there is some good reason to deliberately not make Bootstrap's
classloader the parent class loader of the common class loader, then
my patch needs to be reworked.  But, I couldn't think of any reasons.
And, I could think of reasons why you would want to make Bootstrap's
class loader the parent of the common class loader..

In the classloader.html doc, it says that the "Common" class loader's
parent is supposed to be the "System" class loader (that is to say,
the class loader created from the contents of CLASSPATH at runtime).
When you run Tomcat stand-alone, this is indeed what happens.  I guess
the "System" class loader is the "default" parent, so it works.  But,
when TomcatBlock created its own class loader, that new class loader
is not the default, so it's never the parent of the "Common" class
loader, so there is no way of adding tools.jar (or other jars) to the
Common class loader's search path.  I suppose this is only a problem
when you're trying to start up Catalina using Bootstrap the way we
need to in order to make the Avalon Block.

Someone else suggested that I use EmbeddedTomcat instead, but from
what I understand that means that I also must implement my own config
system, which I don't really want to do.  :)

So, what my patch to Bootstrap does:  it uses Bootstrap's own class
loader as the parent of the Common class loader.  And, when you run
in stand-alone mode, this is (conveniently) the System class loader.


My next mail shows the files I added.....

-- 
Jason Brittain
Software Engineer, Olliance Inc.        http://www.Olliance.com
Current Maintainer, Locomotive Project  http://www.Locomotive.org