tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <>
Subject Re: [PROPOSAL] JSSI for Tomcat
Date Mon, 11 Dec 2000 03:17:28 GMT wrote:
> [...]
> Ok, too much discutions off-topic - I wouldn't mind if you keep the
>* ( and maybe import some more ), instead of
> org.apache.ssi.util :-)


> > What's needed for integration is, first of all, an interface with
> > these methods:
> >
> >   boolean isServletDefined(Servlet context, String servletName);
> >   void addServlet(String className, Hashtable initParams);
> >   void executeServlet(ServletRequest req, ServletResponse res)
> > This interface can be called org.apache.ssi.integration.ServletExecutor
> > and live in the ssi/src/share part of the CVS repository.
> > Implementations of this interface for various containers live in
> > the ssi/integration part of the tree. For Tomcat 3.2, it's implemented
> > by a class in the org.apache.tomcat.facade package.
> If that's all I think we don't need any change in tomcat core, and it
> should work for both 3.2 and 3.3 ( in the form of an interceptor ).
> I'll take a look and try to convert your code to a normal interceptor (
> since this is the best way to extend tomcat3.x ). It would be a great test
> for the model. ( we may need an additional notification/hook for
> "addServlet" - if this is the case we'll need different code for 3.2/3.3 )

Okay, I appreciate if you can take a look at it. I must admit I have not
looked at the interceptor stuff enough to see how it should be done. To
me, "interceptor" sounds like something that intercepts a specific request
and does something with it, not a component that can provide an interface
to non-request related internal functions. 

But maybe I'm missing something. Are you saying the whole SSI processing 
should be done as an interceptor instead of as a servlet? That may work, 
assuming an interceptor can do what the methods in the interface requires.
If so, it can be done as an interceptor for TC 3.x and as a Servlet 2.3 
filter for TC 4.x.

Let me also correct the interface API first so you know what to look at. I
missed the servletContext argument in two of the methods. This is how it
should look like:

  boolean isServletDefined(ServletContext context, String servletName);
  void addServlet(ServletContext context, String className, Hashtable
  void executeServlet(ServletContext context, ServletRequest req,
ServletResponse res);

> > Would the above work even after you "sealed" the facade package? If not,
> > do you have a better suggestion?
> For 3.2 - the package is not sealed, no problem. I think Interceptor
> should be the best way to extend tomcat and integrate other components
> with tomcat - if the provided hooks are not enough it's a great chance to
> add what's needed.
> "Sealed" is an attribute in the Manifest of a .jar file, and it means ( if
> the container uses a "standard" class loader, what we do ) that classes in
> that particular package can't be defined in any other jar ( or classpath
> directory ). It's great to insure that "package" protection is effective.

Ah, got ya :-) 

Hans Bergsten
Gefion Software
Author of JavaServer Pages (O'Reilly),

View raw message