Registration of Tomcat.Next Interceptors

[ru...@us.ibm.com]

How do the new Interceptors interfaces relate to the previously existing
LifecycleInterceptor and ServiceInterceptor interfaces?  In particular,
will it be possible to register the new interceptors in the ServerConfig
file like the previous ones were?

- Sam Ruby

Re: cvs commit: jakarta-tools moo.jar

[co...@eng.sun.com]

>
> IMHO, the nightly build machines should first do a get.all, then run ant's
> bootstrap.sh, then build main.xml all.  In order to ensure that the system
> will recover in the unlikely event that someone catastrophically breaks
> ant, the get.all step should be run with the last released ant.  All the
> remaining build step should be run with this version of ant which was built
> from the most recent source.

Agree with you. Can it wait one more week ( after 15 when I want to finish
with the cleanup stuff )?

It would help if you can set up everithing on your machine, make sure it works

as you wish, and send the crontab and scripts as you want. I can do that,
but have no time right now.

You can start by doing that on your account on jakarta.apache.org, it is
usefull to have BSD builds and it would be easy to get in sync.
Let me know when you're done, and I'll copy the scripts from
your home to the build machines. Sorry, I don't think it's possible
to give access to the build machines, but you can set up your
own and if you get everything working we can pull stuff from
you ( AIX builds / test results ? )

Costin

Re: Registration of Tomcat.Next Interceptors

[co...@eng.sun.com]

rubys@us.ibm.com wrote:

> How do the new Interceptors interfaces relate to the previously existing
> LifecycleInterceptor and ServiceInterceptor interfaces?  In particular,
> will it be possible to register the new interceptors in the ServerConfig
> file like the previous ones were?

I would preffer  "typed" intreceptors ( LifecycleInterceptor,
RequestInterceptor,
ContextInterceptor, ServiceInterceptor, etc).

The configuration is in work, I think it's better to clean up the process
first
before adding new stuff ( see my proposal). We can work in paralel.

Please join the discussion about how Interceptor interface should look, it
is very important to get your opinions, after we conclude the discussion
it will be implemented and will not change very easy!!!

Costin

Re: Registration of Tomcat.Next Interceptors

["Craig R. McClanahan" <cm...@mytownnet.com>]

rubys@us.ibm.com wrote:

> How do the new Interceptors interfaces relate to the previously existing
> LifecycleInterceptor and ServiceInterceptor interfaces?  In particular,
> will it be possible to register the new interceptors in the ServerConfig
> file like the previous ones were?
>
> - Sam Ruby
>

The intent was to replace the existing ServiceInterceptor approach,
although no existing code uses the new design yet -- it depends on
implementing the new container design.

I just answered a question from Hans about the architecture (on another
thread), and drew a picture that illustrated some of the motivation for
this design approach.

Craig

Re: Registration of Tomcat.Next Interceptors

["Craig R. McClanahan" <cm...@mytownnet.com>]

rubys@us.ibm.com wrote:

> How do the new Interceptors interfaces relate to the previously existing
> LifecycleInterceptor and ServiceInterceptor interfaces?  In particular,
> will it be possible to register the new interceptors in the ServerConfig
> file like the previous ones were?
>
> - Sam Ruby
>

Of course, it would help if I answered your second question .....

My thinking is that you'd be configuring the new interceptors (and all the
other components) based on new elements in the server.xml file.  Because
you don't know ahead of time what attributes a particular component cares
about, you'd need to do this without trying to run a validating parser.  An
example configuration of a context might go something like this:

    <Context name="..."
        ...
        <Interceptor className="org.apache.tomcat.logger.AccessLogProducer"

            directoryPath="/usr/local/tomcat/logs" />
        ...
        <Interceptor
className="org.apache.tomcat.security.SecurityInterceptor">
            <Realm className="org.apache.tomcat.security.JdbcRealm"
                ... other attributes defining access to the security stuff
via JDBC ... />
        </Interceptor>
        ...
        <Manager className="org.apache.tomcat.session.SwappingManager"
            checkInterval="60">
            <Store className="org.apache.tomcat.session.FileStore"
                directoryPath="/usr/local/sessions" />
        </Manager>
        ...

    </Context>

The configurator for the context container would process all the existing
stuff, plus it knows what to do on an <Interceptor> or <Manager> element:

* Dynamically instantiate an instance of the class specified
  by the className attribute

* If the new class implements the Lifecycle interface,
  call it's configure() method and pass the node being
  processed (i.e. the <Interceptor> node to an interceptor)
  and then call it's start() method.

* The subordinate elements would themselves dynamically
  create sub-components that they require, using the
  same approach recursively.

This kind of approach would provide lots of flexibility without having to
create all of the "deployment" type objects that are used once and then
thrown away.  This substantially lessens the amount of work required to
implement a new component.

Craig