Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
Costin, [EMAIL PROTECTED] wrote: Patrick ( if you read this ) - what's the status with the 'guess home' ? I can use IntrospectionUtils - it has the whole thing in it ( home/base setting, find in classpath ). We already need IU for jk - it just needs to be included in bootstrap.jar to do that. I haven't ported this yet but I can do it very quickly. The question is where should we put it? Originally, I was going to put it in the Bootstrap.getCatalinaHome() method. However, since we are moving towards using CatalinaService, do you think I should put it there? Patrick -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
On Thu, 15 Aug 2002, Patrick Luby wrote: Costin, [EMAIL PROTECTED] wrote: Patrick ( if you read this ) - what's the status with the 'guess home' ? I can use IntrospectionUtils - it has the whole thing in it ( home/base setting, find in classpath ). We already need IU for jk - it just needs to be included in bootstrap.jar to do that. I haven't ported this yet but I can do it very quickly. The question is where should we put it? Originally, I was going to put it in the Bootstrap.getCatalinaHome() method. However, since we are moving towards using CatalinaService, do you think I should put it there? Probably Bootrstrap is the best place - since it needs to construct the classpath to load CatalinaService ( so it needs it ). If you just include IntrospectionUtil from j-t-c you get it all - ( it is used in jk already ). All you need ( besides build.xml changes ) is: home= IntrospectionUtils.guessInstall(catalina.home, catalina.base, bootstrap.jar, org.apache.catalina.startup.CatalinaService); That will set catalina.home/catalina.base: - if only one is set the other will take that value. - if none is set, it'll look in CLASSPATH for bootstrap.jar and go one level up, or for org/apache... if classes/ is used - and set catalina.home fromt that. You don't need to port it - it is useable directly. ( well, you can cutpaste the method if you want, it's independent of the rest ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
Costin, I took a look at InspectionUtils.guessInstall() and it looks OK. However, it has one limitation: it looks at the classpath to guess the install directory. This works in most cases, but does not work when the InspectionUtils class is loaded in a classloader. Since both the commons-launcher and some J2EE servers load Tomcat's Bootstrap class via a classloader, InspectionUtils.guessInstall() may not work correctly. The way I worked around this in commons-launcher was to invoke the getResource() resource on the class e.g. Bootstrap.class.getResource(/ + Bootstrap.class.getName() + .class) to get the classpath element that this main class was loaded from. This works even if another application is loading your application using a classloader. At this point, I could port this getResource() logic into InspectionUtils or I can put this code directly in Bootstrap.java. What is your preference? Patrick [EMAIL PROTECTED] wrote: On Thu, 15 Aug 2002, Patrick Luby wrote: Costin, [EMAIL PROTECTED] wrote: Patrick ( if you read this ) - what's the status with the 'guess home' ? I can use IntrospectionUtils - it has the whole thing in it ( home/base setting, find in classpath ). We already need IU for jk - it just needs to be included in bootstrap.jar to do that. I haven't ported this yet but I can do it very quickly. The question is where should we put it? Originally, I was going to put it in the Bootstrap.getCatalinaHome() method. However, since we are moving towards using CatalinaService, do you think I should put it there? Probably Bootrstrap is the best place - since it needs to construct the classpath to load CatalinaService ( so it needs it ). If you just include IntrospectionUtil from j-t-c you get it all - ( it is used in jk already ). All you need ( besides build.xml changes ) is: home= IntrospectionUtils.guessInstall(catalina.home, catalina.base, bootstrap.jar, org.apache.catalina.startup.CatalinaService); That will set catalina.home/catalina.base: - if only one is set the other will take that value. - if none is set, it'll look in CLASSPATH for bootstrap.jar and go one level up, or for org/apache... if classes/ is used - and set catalina.home fromt that. You don't need to port it - it is useable directly. ( well, you can cutpaste the method if you want, it's independent of the rest ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- _ Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 _ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
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]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
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/
[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]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
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
everywhereThe 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]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
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. Ok. 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. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
On Wed, 14 Aug 2002, Jean-francois Arcand wrote:
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
everywhereThe only solution will be to set the schema validation
off, or detect the Xerces version and throw an exception before starting
parsing a file.
Turn schema validation off, and leave it off. Tomcat5 working with a
single parser is not good.
And while you're doing that, turn also DTD validation off and leave it
off unless a user wants to enable it explicitely.
Validation should be done by a deploy tool or build tool ( offline ).
Or by tomcat if a mechanism to avoid duplicated validation is provided.
Costin
-- 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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
[EMAIL PROTECTED] wrote: On Wed, 14 Aug 2002, Jean-francois Arcand wrote: 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 everywhereThe only solution will be to set the schema validation off, or detect the Xerces version and throw an exception before starting parsing a file. Turn schema validation off, and leave it off. Tomcat5 working with a single parser is not good. And while you're doing that, turn also DTD validation off and leave it off unless a user wants to enable it explicitely. Validation should be done by a deploy tool or build tool ( offline ). Or by tomcat if a mechanism to avoid duplicated validation is provided. +1 ! Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
Jean-francois Arcand wrote: 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 everywhereThe only solution will be to set the schema validation off, or detect the Xerces version and throw an exception before starting parsing a file. Yes, it's Xerces 2.0.2. At least that's what the README claims. From what I understand it's not sufficient to turn schema validation off, although I haven't verified that. Is there a good way of detecting which version of Xerces is present? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
[EMAIL PROTECTED] wrote:
SNIP/
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 ).
See attached patch. I added a method setHomeAndBase() and a couple of
booleans to see if they were set via setters.
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.
With any luck, by the time Tomcat5 is released, XML parsers with good
schema support will be more common, so it won't be such an issue. It is
unfortunate that the current release of Xerces is broken.
Removing validation from the servlet container reference implementation
somehow seems, well, wrong. I agree that doing validation at deployment
is reasonable, rather than for each startup. Something like what the jsp
compiler does.
SNIP
java fork=false will run it in process, which gives problems with
the shared environment. In particular I get:
[java] INFO: Digester for server.xml created 587
[java] java.lang.LinkageError: loader constraints violated when
linking org/xml/sax/XMLReader class
java fork=true will run it out of process, but the next task won't
execute until tomcat finishes. Not good either.
I think the right answer is either Launcher, which uses [daemon] to
start a background process, or Cactus, which introduces another
dependency, and may still have some issues with the ant environment
leaking through.
Regarding output redirection, I think Patrick mentioned adding some
methods in the startup code to redirect programmatically.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Index: catalina/src/share/org/apache/catalina/startup/CatalinaService.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaService.java,v
retrieving revision 1.2
diff -u -w -r1.2 CatalinaService.java
--- catalina/src/share/org/apache/catalina/startup/CatalinaService.java 10 Aug 2002
16:54:15 - 1.2
+++ catalina/src/share/org/apache/catalina/startup/CatalinaService.java 14 Aug 2002
+21:39:39 -
@@ -158,11 +158,34 @@
}
+private boolean homeSet = false;
+private boolean baseSet = false;
+
public void setHome( String s ) {
System.setProperty(catalina.home, s );
+homeSet = true;
+}
+
+public void setBase( String s ) {
System.setProperty(catalina.base, s );
+baseSet = true;
}
+
+protected void setupBaseAndHome() {
+if (homeSet baseSet) return;
+if (!homeSet !baseSet) return;
+if (homeSet !baseSet) {
+System.setProperty(catalina.base, System.getProperty(catalina.home));
+return;
+}
+if (!homeSet baseSet) {
+System.setProperty(catalina.home, System.getProperty(catalina.base));
+return;
+}
+}
+
+
public void setUseNaming( boolean b ) {
useNaming=b;
}
@@ -196,6 +219,7 @@
// make sure the thread loader is set
log.info(Running tomcat5);
Thread.currentThread().setContextClassLoader(
this.getClass().getClassLoader());
+setupBaseAndHome();
if (starting) {
load();
start();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
On Wed, 14 Aug 2002, Steve Downey wrote: See attached patch. I added a method setHomeAndBase() and a couple of booleans to see if they were set via setters. Ok. I made few changes, I'll commit later. Patrick ( if you read this ) - what's the status with the 'guess home' ? I can use IntrospectionUtils - it has the whole thing in it ( home/base setting, find in classpath ). We already need IU for jk - it just needs to be included in bootstrap.jar to do that. With any luck, by the time Tomcat5 is released, XML parsers with good schema support will be more common, so it won't be such an issue. It is unfortunate that the current release of Xerces is broken. I kind of doubt too many parsers will support schema - it is a very heavy specification. And unless JDK1.5 is released by then, the parser included in jdk1.4 will not support schema. Removing validation from the servlet container reference implementation somehow seems, well, wrong. I agree that doing validation at deployment is reasonable, rather than for each startup. Something like what the jsp compiler does. It's not 'removing' - just moving to the right place. And doing it at runtime ( and on every startup ) sets a bad example, for a RI :-) java fork=false will run it in process, which gives problems with the shared environment. In particular I get: [java] INFO: Digester for server.xml created 587 [java] java.lang.LinkageError: loader constraints violated when linking org/xml/sax/XMLReader class Yes, that's a bug in ant1.5 class loader. I assume you use jdk1.4 :-) It works ( for me ) with CVS head. java fork=true will run it out of process, but the next task won't execute until tomcat finishes. Not good either. I'll think about it. I can fix java to wait for a token and detach ( or at least return control ). I think the right answer is either Launcher, which uses [daemon] to start a background process, or Cactus, which introduces another From what I see in the [daemon] code it won't solve the problem - on unix it seems to wait in a loop, it won't return. I need to try again. I'm not sure how is cactus solving the problem. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
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.
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.xml,v
retrieving revision 1.26
diff -u -w -r1.26 build.xml
--- build.xml 13 Aug 2002 16:59:12 - 1.26
+++ build.xml 14 Aug 2002 05:05:42 -
@@ -29,6 +29,8 @@
value=${basedir}/../jakarta-tomcat-jasper/jasper2/
property name=jtc.home
value=${basedir}/../jakarta-tomcat-connectors/
+ property name=watchdog.home
+ value=${basedir}/../jakarta-watchdog-4.0/
!-- Build Defaults --
property name=catalina.build value=${catalina.home}/build/
@@ -51,6 +53,7 @@
echo message=catalina.home=${catalina.home}/
echo message=jasper.home=${jasper.home}/
echo message=jtc.home=${jtc.home}/
+echo message=watchdog.home=${watchdog.home}/
ant dir=${catalina.home} target=flags.display/
@@ -151,6 +154,66 @@
/ant
/target
+ !-- === WATCHDOG: Run Watchdog Tests --
+ target name=watchdog
+ description=Watchdog Servlet Container Tests
+ant dir=${watchdog.home} target=dist
+ property name=servlet23api.home value=${api.home}/
+ property name=servlet22api.home value=${basedir}/../jakarta-servletapi/
+/ant
+delete dir=${basedir}/tmp/tomcat/
+mkdir dir=${basedir}/tmp/tomcat/
+copy todir=${basedir}/tmp/tomcat/conf
+ fileset dir=${tomcat.build}/conf/
+/copy
+copy todir=${basedir}/tmp/tomcat/webapps
+ fileset dir=${tomcat.build}/webapps/
+/copy
+copy todir=${basedir}/tmp/tomcat/work
+ fileset dir=${tomcat.build}/work/
+/copy
+copy todir=${basedir}/tmp/tomcat/logs
+ fileset dir=${tomcat.build}/logs/
+/copy
+copy todir=${basedir}/tmp/tomcat/webapps
+ fileset dir=${watchdog.home}/dist/webapps/
+/copy
+
+
+java classname=LauncherBootstrap fork=yes
+ jvmarg value=-Dcatalina.home=${tomcat.build}/
+ jvmarg value=-Dcatalina.base=${basedir}/tmp/tomcat/
+ arg value=-launchfile/
+ arg value=catalina.xml/
+ arg value=-verbose/
+ arg value=catalina/
+ arg value=start/
+ classpath
+pathelement path=${java.class.path}/
+ pathelement path=${tomcat.build}/bin/
+ /classpath
+/java
+
+sleep seconds=15/
+
+ant dir=${watchdog.home}/dist target=all/
+
+java classname=LauncherBootstrap fork=yes
+ jvmarg value=-Dcatalina.home=${tomcat.build}/
+ jvmarg value=-Dcatalina.base=${basedir}/tmp/tomcat/
+ arg value=-launchfile/
+ arg value=catalina.xml/
+ arg value=-verbose/
+ arg value=catalina/
+ arg value=stop/
+ classpath
+pathelement path=${java.class.path}/
+ pathelement path=${tomcat.build}/bin/
+ /classpath
+/java
+
+ /target
+
!-- == DIST: Create Directories --
target name=dist-prepare
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
