> > status - there are 2 directories that can be set on
> > ContextManager,
> > one is "home" and the other one is "installDir".
> > The env. variable is used to set home.
>
> Where is this stuff documented? There doesn't seem to
> be a DTD for server.xml.
It's still on the TODO list, but it'll happen only after we
add the <ant> style config directives ( since that will
allow us to define all the attributes for JspInterceptor,
and different attributes for StaticInterceptor - each
module has it's own properties ).
( same problems as in ant - user modules can't be coded
in the dtd ).
BTW, there is already code checked in that will read all
the .java code, and for all classes that extends BaseInterceptor
it'll extract the comments for the setters and generate
a xml file.
The .dtd generation can be easily automated ( the goal
is mostly to generate user documentation for modules
that is in sync with the real code )
> so you seem to be saying that one would set InstallDir
> -> TOMCAT_HOME and home -> APP_HOME. I'll test that
> out.
Confusing, isn't it :-) ?
( it's easy for me to criticize that - I wrote a lot of this
code, so I'm not at risk to offend anyone else :-)
> These issues directly affect configuration management
> and are critical for managing complex deployments. I
> don't think enough people take this area seriously
> enough (code features now, worry about deployment
> later!).
IMHO the biggest problem is that people deploying
tomcat are not providing enough feedback and
are not contributing back code or documentation.
Yes, we had requests for this kind of configuration
( with separate install and user dir ), and the
intial code has been written way ago. I tried
to do it as good as I could - but I can't guess
what's easy and what isn't from a deployment
perspective.
> Why exactly would it be 'much' slower? Does that
> presume that a custom JspServlet would be inherently
> slower or that the default
> org.apache.jasper.runtime.JspServlet is somehow
> accellerated by something JspInterceptor does?
No, the overhead of using a servlet to invoke the
jsp page is significant ( at least in my tests
is shows a big difference ).
JspInterceptor does a simple thing - after the
jsp page is compiled to a servlet, the servlet
will be "registered" to tomcat ( as if it was
declared in web.xml ) and after that all
invocations to the jsp page are identical with
invocations for servlets ( with one exception -
jsp_precompile param must be read on each request
and if present, the request shouldn't be
executed - that's the spec ).
( reloading is also done in the same way, using
DependManager ).
> replacement and pre-load it in the CLASSPATH) would
> that be 'much slower' (even though it should not
> require setting the 'useJspServlet' tag since it would
> appear to be the regular default class)? Just curious
> about your statement.
Try it yourself, send back the results :-)
( ab -n 10000 -c 80 http://localhost:8080/foo.jsp
with JspInterceptor in both modes ).
( useJspServlet means JspInterceptor will do nothing,
just return ).
( of course, you can compare 3.3 with JspInterceptor with
3.2.1 without it - but there are other factors in that)
( as developer I do this kind of tests quite often
to track if the changes are affecting the performance,
and everyone should do it once in a while )
> processing servlet (or any default servlet) with no
> more work than changing a line in a configuration
> file. It sounds like 3.3 brings this ease in the
> JspInterceptor.
Well, it is possible in 3.2 also, but you need
a special module that will set the jsp implementation.
It's not hard to do, but it's not there by default.
( I sent to the list one that changed jasper settings,
you just need to add few lines to change jasper with
a different one). The module will do nothing else,
just alter some settings - you add it to server.xml.
> I'm pretty intimate with the Jasper API, but still
> learning the Tomcat API. I'm still working on
> understanding how the Connector and Interceptor
> patterns are implemented.
A good news - in 3.3 there is no Connector API :-)
( the Connector is just a regular module )
( well, we are still far away from the rafinaments
in Apache 2.0 where even the threads are managed by a
plugable module - but the model for modularization
is close )
--
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
