tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
Date Wed, 14 Aug 2002 19:50:31 GMT
On Wed, 14 Aug 2002, Steve Downey wrote:

> First is that o.a.c.startup.CatalinaService doesn't distinguish between 
> catalina.home and catalina.base. setHome() actually sets both of them. 
> Adding a setBase() is trivial, but it affects the semantics of 
> initialization. Any current client expects both to be set by a call to 
> setHome(),  and just moving the setProperty to setBase() breaks that. Of 
> course if the setProperty("catalina.base",s) is left in setHome(), then 
> initialization is order dependent. For now, and I just added a setBase() 
> and ignored the problem.

Well, CatalinaService is not 'completed' - just started :-)

What we do in 3.3 is have 2 setters, and at execute check if:
- if only one is set, the other takes this value
- if none is set, use discovery ( locate the base from the CLASSPATH )
- if both are set, use that.

If you want to implement this - great, if not I'll do it when I find 
time ( or I need it ).

> The next problem was that the task runs in VM. Ant's xercesImpl chokes 
> on parsing the schemas. This is the known dependency on Xerces 2.0.1. 
> Replacing the xercesImpl.jar in Ant fixed that, but that seems an ugly 
> requirement.

Well... As I said, it is a major problem if we can't use any JAXP but 
require a specific parser and version...

One solution is to remove schema validation ( and validation in general )
from tomcat runtime, and have a separate validation program that
can be run on a webapp _before_ it is deployed on tomcat. 

There are many other solutions - but requiring anyone using tomcat5
to use Xerces2.0.1 and subjecting every user to hugely expensive
and redundant validation is the worse.

> In any case, after doing that, Catalina service starts up, but doesn't 
> seem to be able to find the servlet apis to compile JSP pages. As an 
> added irritation, stdout isn't redirected to catalina.out, and it is 
> quite noisy.

Yes - I have few more classes to convert to commons-logging, after
that we'll have full control over the messages and verbosity.
I'll probably commit somthing this weekend ( large commit, need
to filter out some changes and test more ).

Regarding servlet apis - it may be a bug in AnClasstLoader. I use CVS_HEAD
and it works fine for me, but I had the same problem with 1.5.
I can try to find a workaround ( I think I've seen a fix in the 1.5
branch for classloader that may fix this, so you can use the head
of 1.5 branch as well ).

I love classloaders and reverse delegation...

> So, my current patch may not be the best possible, but it does have the 
> advantage of working.


> I think it will make more sense to use the launcher as the basis for a 
> task to run tomcat. Running it in process leads to a lot of state 
> leaking over. For testing I think it's safer to run it as much as 
> possible in its own environment.

You can also use <java execute> ( it is commented out in build2.xml, 
but should work fine ).

Regarding output redirection, I think Patrick mentioned adding some
methods in the startup code to redirect programmatically.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message