tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <steve.dow...@netfolio.com>
Subject Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
Date Wed, 14 Aug 2002 19:35:55 GMT
Thanks for pointing the tomcat5 task out. I'm trying to reimplement with 
that, and have run into a couple of snags.

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.

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.

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.

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.

This is what I was using for the tomcat5 task:
    <property name="tools.jar"
                   location="${java.home}/../lib/tools.jar" />
    <path id="tomcatcp" >
      <pathelement location="${tomcat.build}/server/classes"/>
      <pathelement location="${tools.jar}" />
      <fileset dir="${tomcat.build}/server/lib">
        <include name="**/*.jar"/>
      </fileset>
      <fileset dir="${tomcat.build}/common/lib">
        <include name="**/*.jar"/>
      </fileset>
      <fileset dir="${tomcat.build}/common/endorsed">
         <include name="**/*.jar"/>
      </fileset>
      <fileset dir="${tomcat.build}/shared/lib">
         <include name="**/*.jar"/>
      </fileset>
    </path>
   
    <taskdef name="tomcat5"
                  classname="org.apache.catalina.startup.CatalinaService"
                  classpathref="tomcatcp" />
    <tomcat5 do="start"
                   home="${tomcat.build}"
                   base="${basedir}/tmp/tomcat"
                   wait="false"/>


costinm@covalent.net wrote:

>On Wed, 14 Aug 2002, Steve Downey wrote:
>
>>This patch starts up a copy of tomcat with the watchdog war files, runs 
>>watchdog against it, and shuts down tomcat afterwards. It uses the Launcher 
>>to run tomcat in the background, and puts the webapps, work, logs and conf 
>>directories in a tmp dir so as not to muck up the build.
>>
>>The only part I really don't like is that there isn't a good way to know that 
>>tomcat is up and running, so for now there's a sleep between launching tomcat 
>>and starting the watchdog tests.
>>
>
>For tomcat5 ? Well, it is - if you use the task ( take a look at 
>build2.xml ). The task will start tomcat inprocess, and will return 
>after all the startup is done ( and continue with the next task ).
>
>( unless you have wait="true" )
>
>Costin
>
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
>
>




--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message