Quoting [EMAIL PROTECTED]:
> 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 :-)
So I gathered ;-)
> The processing is very simple. First, modules.xml is read - like
> taskdefs in ant, it associates a tag name with a java class.
Cool. I also got a detailed "how to set up your config files for the new module
system" from Larry, so a big thanks to him as well (he's having IMAP woes :( so
he forwarded it privately so that I could code on it ALL NIGHT tonight :-).
I wasn't aware that the <RequestInterceptor> approach was more-or-less the
deprecated way to interface a module, which would explain some of my confusion.
Since the newer way sounds not only ... well, newer ... but also easier, I'll
go with that. I really dig the way that the tag attributes have a corresponding
setter methods in the object; how if I just name the setters correctly,
everything just happens ... very slick.
> I know, XmlMapper is a very bad hack.
*shrug* ... Honestly, I couldn't tell you. I just know that my little brain
couldn't process that level of abstraction at 5:30pm after having just finished
a 4-hour whirlwind crash course in general container startup and config. It's
kind of like giving a caveman a Packard Bell computer. He doesn't know if it's
genius or not. He just knows that it's shiny and does things he doesn't
understand. You should have just told me it was brilliant ;-)
(Incidentally, and continuing my theme from the newly-ressurected "source code
in the binaries" thread, I would like to propose in advance that the Tomcat 5
codebase be codenamed "Milton".)
> I'm working on a replacement ( as a 3.3 module, of course :-).
...
> > 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.
By all means, my friend. Since I have no earthly idea what either the admin or
ajp12 passwords do, or what they are, I promise not mind =)
Seriously, though, just keep in mind that I am planning that broader "External
Resource Security" module (explained in a half-assed fashion in a previous
post). I haven't gotten any committer feedback on that yet, so I'm not sure
what the general sentiments are on it. Of course if you don't personally like
that one, or if the idea doesn't fly in general, I would have absolutely no
objections to anyone extending this mod to suit their needs. But if you like
the idea, those things may be perfect candidates for my "centralized
repository" approach.
> I think what you want is a configuration module, not a http ( connector )
> module. Even if it would work if you extend Http10Interceptor, it would not be
> very clean.
Yeah, that makes more sense. I was confused by the RequestInterceptor business,
primarily because I couldn't see how to hook into the process without mimicking
the current https RequestInterceptor. My module's lifecycle is complete once
the user types in the password and hits ENTER, so leaving it sitting there in
the middle of the request/response chain seemed weird. I now see how I can be a
load-time module without being a connector.
Thanks for the info!
- Christopher
