[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
