>
> 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:
That's another issue, and I kept asking for such a thing for a long time.
Having a common package for utilities that are independent of a particular
project is one of my biggest wishes ( for next year - Christmas is too
close :-).
Most of the code in org.apache.tomcat.util ( and most of tomcat3.3 ) is
organized as a set of container-independent, general purpose utils (
optimized for server side use, but without any dependency on tomcat ) and
a simple set of tomcat-specific interfaces.
I am working on a better organization ( to reduce namespace polution in
tomcat.util), but there are many great tools in org.apache.java from the
JServ project, and few great tools in xerces - all those should be
organized under the same hierarchy, with a build system that would allow
projects to pick what they need.
Ok, too much discutions off-topic - I wouldn't mind if you keep the
org.apache.java.* ( 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 )
> > 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?
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.
Costin
