Steve Downey wrote:
> 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.
The problem should occurs only with Xerces 2.0.2. Is 2.0.2 bundle with
ANT 1.5? If you try with the current Xerces nightly build, it should
work. This is a big paint because Xerces 2.0.2 seems to be used
everywhere....The only solution will be to set the schema validation
off, or detect the Xerces version and throw an exception before starting
parsing a file.
-- Jeanfrancois
>
>
> 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"/>
>
>
> [EMAIL PROTECTED] 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:[EMAIL PROTECTED]>
>> For additional commands, e-mail:
>> <mailto:[EMAIL PROTECTED]>
>>
>>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
