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]>
