tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <h...@gefionsoftware.com>
Subject Re: [PROPOSAL] JSSI for Tomcat
Date Sun, 10 Dec 2000 20:01:18 GMT
cmanolache@yahoo.com wrote:
> [...]
> > 1) Make this a new Jakarta subproject, named jakarta-jssi.
> >    The reason for this is that it's an optional module and it can
> >    live its own life outside the container development.
> 
> +1  - but I would like more a "generic" name ( jakarta-jsse - java server
> side extensions ). JSSI seems a small project and it may not be worth the
> overhead of a top level modules.
> 
> That will reduce the pressure on tomcat for developing feature-isms and
> non-standard extensions, and will keep it more focused on strict
> implementation of the servlet API. The extensions could be developed
> independent of tomcat, and maybe will be reused in other containers. As an
> additional benefit, people will not confuse "extensions" with
> "standards" :-)

That's a good idea, and jakarta-jsse is as good a name as any ;-)
This subproject could then be modeled after the jakarta-taglibs
project, with independent modules that have their own documentation,
can be downloaded separately, etc. (See the Jakarta-Taglibs web site
for details). I believe this project will be a good place for a
collection of Servlet 2.3 filters eventually. See more below for container 
integration.

> > 3) Package structure (for TC 3.2 version)
> >    In order to integrate with Tomcat's Context and ServletWrapper classes
> >    (for servlet loading and execution), the JSSI classes should be in
> >    org.apache.tomcat.* packages, and at least one of them must be in the
> >    org.apache.tomcat.facade package specifically. Keeping basically the
> >    original internal package structure but adjusted to Tomcat, I suggest
> >    the following packages:
> >
> >       org.apache.tomcat.facade
> >         One class (ServletTagHandler)
> >       org.apache.tomcat.ssi
> >         Main classes
> >       org.apache.tomcat.ssi.util
> >         SGMLTag
> >       org.apache.tomcat.ssi.io
> >         PositionReader
> 
> My preference would be org.apache.ssi ( no tomcat in package ).
> Reason - other containers could use it. Tomcat is an implementation of the
> servlet API, we should use the package only for that :-)

Okay, the current JSSI packages are:

  org.apache.java.io (one class, PositionReader)
  org.apache.java.util (one class, SGMLTag)
  org.apache.servlet.ssi (the rest)

Even though the "org.apache.java.*" classes are not directly tied to
JSSI, I have a feeling they are not all that useful for other projects.
And without a real "shared Java utils" package within Apache, it's a
pain to coordinate the development of shared code. I therefore suggest 
this structure initially instead:

  org.apache.ssi.io (one class, PositionReader)
  org.apache.ssi.util (one class, SGMLTag)
  org.apache.ssi.servlet (the rest)

For Servlet 2.3 containers, SSI can likely be implemented as a filter
instead. At that point, we can clean-up and move some of the classes 
from org.apache.ssi.servlet to a new package (org.apache.ssi.core),
and add the filter interface in a new package (org.apache.ssi.filter).


> The facade class should be in a different directory ( something like
> src/share, src/tomcat32_integration, src/jserc, ... ), and we should
> help people to create code to integrate with other servlet containers.

Okay, how about this: the packages above are stored in a directory
named ssi/src/share and the integration classes are stored in a
directory named ssi/integration/tomcat_3.2 (etc.), all within the
CVS repository for jakarta-jsse.

What's needed for integration is, first of all, an interface with
these methods:

  /**
   * Returns true if the named servlet is known by the context.
   */
  boolean isServletDefined(Servlet context, String servletName);

  /**
   * Adds the servlet class to the context, using the className
   * as the servlet name. After this call, a call to isServletDefined()
   * with className as servletName must return true. The initParams
   * must be used when the servlet is initialized.
   */
  void addServlet(String className, Hashtable initParams);

  /**
   * Calls the servlet's service() method with the specified
   * request and response object, loading and initializing the
   * servlet first if needed.
   */
  void executeServlet(ServletRequest req, ServletResponse res)
    throws IOException, ServletException;
  
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.

> One comment about the "facade" class - the plan is ( sometime in 3.3 ) to
> "seal" the facade package. There are many security implications, the
> facade is a critical component for tomcat's security. This shouldn't be
> a big problem, but an oportunity to learn and maybe provide better hooks
> for applications like that :-)

Would the above work even after you "sealed" the facade package? If not,
do you have a better suggestion?

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

Mime
View raw message