tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Cert Lockdown - 3.3 Integration
Date Thu, 02 Aug 2001 03:12:03 GMT
On Wed, 1 Aug 2001, Christopher Cain wrote:

> I followed the whole startup routine from Tomcat.startTomcat() all the
> way through where the ContextManager calls the
> ServerXMLReader.addInterceptor(). That's where the whole hairy-chested
> XML parsing begins, and my brain started hurting :-) Up to the point, I
> have a pretty good grasp of the process.

That's where the fun starts :-)

ServerXmlReader is just a normal interceptor. When the addInterceptor hook
is called ( telling ServerXmlReader it has been added to tomcat), it'll
read server.xml file and process it ( in general any module can add other
modules or contribute to the configuration process - in previous versions
the configuration was hardcoded, now it's just another module ).

The processing is very simple. First, modules.xml is read - like taskdefs
in ant, it associates a tag name with a java class.

The for every line in server.xml, the tag is used to construct a class,
then with introspection we set all the properties ( each attribute
coresponds to a setter ).

So if you have
class MyModule extends BaseInterceptor {
  public void setFoo(String s ) {


You do a:
<module name="my" classname="my.MyModule" />

and in server.xml:
<my foo="bar" />

That's all. XmlMapper will do all the magic.

> So basically, the only part of the entire process that I'm missing is
> the one that I need: How we get from a <RequestInterceptor> tag in
> server.xml to an instantiated class that extends BaseInterceptor. I have
> the following knowledge:

<RequestInterceptor > is "old style", basically it uses the class=".."
attribute to construct the class.

I prefer the new ant-like style, but both should work.

> - The PoolTCPConnector has an "attributes" hashtable

> - It also has a "setKeyspass()" method which sets a "keypass" value in
> the hashtable (which a grep of the source tree turned up no specific
> calls to)

Yes, flexibility syndrome.

The idea is that XmlMapper can take <propery name="foo" value="bar" />
and call SetAttribute.

The attributes are passed to the SocketFactory, so this allows to pass
arbitrary atributes without changing the code. For the common keypass,
etc we have explicit setters ( much cleaner ).

> So my question to you is, can you fill in the last piece of the puzzle
> for me? I know, I know ... I really should be smart enough to follow the
> startup code through the XMLMapper jungle, and I feel stupid for asking.

I know, XmlMapper is a very bad hack. I'm working on a replacement ( as a
3.3 module, of course :-).

The main benefit is that's very flexible ( but you can reach it's limits,
and the speed can be improved significantely - the original reason to do
XmlMapper was speed, as it was much faster then using DOM ).

Until the replacement is ready, just treat it like a black box that
creates objects and calls setters for each attribute, and don't try to
hard to look into details.

> Finally, is the right answer to create a class that extends
> Http10Interceptor? It would inherit everything as-is, then adds a calls
> out to my (self-contained for portability) "prompt getter" class,
> calling the existing PoolTCPConnector.setKeypass() method with the

I don't think it's a good idea - just write a class that extends
BaseInterceptor, with all the attributes you need, then search for the
Http10Interceptor and set the property.

I hope I can extended a bit your module, after you're done, to
check if the admin password and ajp12 passwords are set - and if not to
prompt the user. Far too many users forget this.

I think what you want is a configuration module, not a http ( connector )
Even if it would work if you extend Http10Interceptor, it would not be
very clean.


View raw message