Jacob, if you could try to substantiate your reports, that would be great. This
doesn't help anyone.
AFAIK, there has never been any getHost method inside StandardHost, and there
hasn't been any change between the StdHost from 5.0.3 and the StdHost from CVS
HEAD. I would appreciate if you could debug a bit your setup, which most of the
time is not exactly clean.

Hi Remy,

I don't have the slightest clue of where to look in Tomcat.  Here is what I know
(and thought was clear in the initial report)...

1.  The problem didn't happen when using any previous version of Tomcat.  That
is, everything works just fine from version 5.0.3 all the way back to all recent
versions of 4.1.xx.

2.  The only thing that changed was pointing CATALINA_HOME to the latest version
of Tomcat built from CVS rather than some other version of Tomcat.  Really,
truly, not one other thing is different.  Not a single change was made to the
application; only the value of CATALINA_HOME in the batch script is different.

Given these premises, the conclusion follows that the problem is not my app, but
something in Tomcat. If that conclusion is just way out of line, please describe
your reasoning.

I'm not saying that the issue is necessarily StandardHost.  What I'm saying is,
that is what the stack trace says.  There is also a NullPointerException further
down the stack trace.  There's a lot of runtime reflection going on there and
what is being reported is probably obscuring the real issue.  What I was hoping
was that the stack trace would be more clear to you than to me and that it would
provide a clue to the real source of the issue.

For your information, here is what the "run-tomcat" batch script looks like...

@echo off
set CATALINA_HOME=C:\Java\Apache\Jakarta\tomcat-5-20030708
set
CATALINA_BASE=D:\myclasses\Repository\Enhydra\XMLC_DSF_2003-05-19-2\xmlc\examples\tomcat\build

rem remove the log files
del /Q %CATALINA_BASE%\logs\*

%CATALINA_HOME%\bin\catalina.bat run


Pretty simple stuff.  Again, the only difference between when things work and
when things don't is the value of CATALINA_HOME above.  Specifically, if I
change it to "C:\Java\Apache\Jakarta\tomcat-5.0.3", then Tomcat starts up just fine.

Your criticism of my bug reports notwithstanding, most all of my bug reports
have lead to important modifications allowing Tomcat to work properly where it
may not have if not for my report because you wouldn't be aware of the issue if
not for the report.  So, I'll try to improve the reports but remember, I'm an
interested Tomcat user, but not a Tomcat developer.  Please keep expectations in
line with that fact.

Let me know if you require any other specific types of information to make it
easier to fix this issue.  I can provide instructions on reproducing the
problem, but that would require you to grab the latest source of XMLC.  I'm not
sure if you are willing to do that or not.  If so, let me know and I'll provide
step-by-step instructions.

Jake

If something really bad happens during init (which doesn't happen in practice),
then the server instance is null, and you should get a NPE.
There's of course no call to any getHost( method (do a grep if you don't believe
me) anywhere in the source - and there never was one -, except on the request
method.
Don't worry, if this bug is real, it seems obvious enough, and other people will
report it.

Can't you really fix that kind of thing ?
log4j:WARN No appenders could be found for logger
(org.apache.catalina.startup.Embedded).
log4j:WARN Please initialize the log4j system properly.

Same problem, here is a small patch from me.

WORKS FOR ME

Index: SetDocBaseRule.java
===================================================================
RCS file: /home/cvspublic/jakarta-tomcat-
catalina/catalina/src/share/org/apache/catalina/startup/SetDocBaseRule.java,v
retrieving revision 1.1
diff -u -w -b -r1.1 SetDocBaseRule.java
--- SetDocBaseRule.java 24 Jun 2003 22:37:05 -0000      1.1
+++ SetDocBaseRule.java 9 Jul 2003 11:24:21 -0000
@@ -118,8 +118,13 @@

         Context child = (Context) digester.peek(0);
         Deployer parent = (Deployer) digester.peek(1);
+        Host host = null;
+        if (!( parent instanceof StandardHost ))  {
         Method method = parent.getClass().getMethod("getHost", null);
-        Host host = (Host) method.invoke(parent, null);
+          host = (Host) method.invoke(parent, null);
+        } else
+          host = (Host)parent;
+
         String appBase = host.getAppBase();

         if (!(host instanceof StandardHost)) {

Sounds convincing enough to me ;-) It seems you made a mistake trying to reopen
the bug.
This doesn't happen in normal mode for me however. how do you reproduce it ?

About the patch: Maybe it could be cleaner, I'll see what I can do. The addition
of a method somewhere could be needed.

Sorry, can't reproduce it in the quick. Seen this exception on my 2 development machines and on my dev-server,after patching SetDocBaseRule to check if its get a StandardHost or other thing, it's work for me. My Setup,dev-server: 1 host + 3 aliases, standalone tomcatdev-machines: 1 host, localhost only

I'm glad someone else is seeing this.  I tried reproducing it by just running
"$CATALINA_HOME/bin/catalina.bat run", but I didn't see the error occur there.

Here is how you can reproduce it for yourself:

1.  Grab the latest XMLC CVS.  See instructions here:
http://forge.objectweb.org/cvs/?group_id=49

2.  cd to the root of the build and follow short instructions in the "README". 
XMLC should now be built.

3.  cd to $XMLC_ROOT/examples/tomcat.  Copy "build.properties.examples" to
"build.properties" and modify the path to "tomcat.home".  Now run "ant".  This
will build the examples and set up an environment for a custom CATALINA_BASE and
use the value you defined for tomcat.home for CATALINA_HOME.  Convenience
scripts "run-tomcat.bat" and "run-tomcat.sh" will be generated for you.

4.  run the appropriate script for your platform.  I run "run-tomcat.bat" on my
win2k platform.  You should now witness the stack trace that I reported if you
are using the latest Tomcat5 CVS.  To test with another version of tomcat,
modify the tomcat.home property in build.properties to, say..., tomcat-5.0.3 and
re-run "ant".  The scripts will be re-generated for you pointing to the
appropriate CATALINA_HOME.  You should not witness the stack trace using
tomcat-5.0.3.

5.  If you care to view the application running under this custom CATALINA_BASE,
point your browser to:
http://localhost:8081/xmlc/

Hopefully those instructions are clear enough.  Let me know if you have
difficulties.


BTW, regarding your comments...

>Can't you really fix that kind of thing ?
>log4j:WARN No appenders could be found for logger
>(org.apache.catalina.startup.Embedded).
>log4j:WARN Please initialize the log4j system properly.

That started happening in recent Tomcat5 builds.  It doesn't occur when using
Tomcat-4.1.xx and actually didn't occur in early builds of Tomcat5 (sorry, not
sure when exactly it started).  I suspect the reason it is happening has more to
do with commons-logging than Log4j.  I put log4j-1.2.8.jar in
CATALINA_HOME/common/lib as a standard practice.  Since commons-logging sees
Log4j in its classpath, it uses it.  The app in question actually uses no
logging whatsoever so this message is coming from something in Tomcat itself (or
its 3rd party libraries) and not the example application.  If you are asking me
to  track down the issue in commons-logging, you are barking up the wrong tree.
 I have nothing to do with commons-logging and, personally, I feel it has caused
way more pain and suffering than it is worth.  The class loading tricks it uses
to proxy other logging api's fails in lots of situations and is incredibly hard
to debug.  If it were up to me, I'd drop commons-logging like a bad habit and
just use Log4j directly.  I know that won't happen, though, so I'm not going to
press the issue.  I can make Log4j work just fine for me in apps using Log4j
directly so the Log4j warning message in question is pretty innocuous to me. 
I'm not sure if the interaction is adversly affecting Tomcat5 logging when
commons-logging finds Log4j in its classpath or not?  As such, I'm not very
worried about it.  If you want to report a bug I'm all for it, but the only
people who will be able to fix it are either Tomcat guys like yourself or
commons-logging guys.  I don't think many people at Log4j will have much
interest or be able to help in any way other than maybe Yoav Shapira who has
more hands-on experience with commons-logging as well as being a Log4j developer.

Jake

Ok, I reproduced it. You only need to have a Context element defined in server.xml.
So since this is not the preferred way in TC 5, I forgot to test it. Torsten's
patch is correct, and I'll apply it. Thanks for the patch.

Jacob: Thanks for reporting the issue. About the log4j problem: I did change
things in the webapp classloader, but not in the main common classloader.