Re: [PROPOSAL] JSSI for Tomcat
Kief Morris wrote: > > Hans Bergsten typed the following on 19:17 10/12/2000 -0800 > >But maybe I'm missing something. Are you saying the whole SSI processing > >should be done as an interceptor instead of as a servlet? > > Is this something that could be done as a Servlet 2.3 Filter, and so be > completely > container independent for 2.3 containers? It can (likely) be done as a filter for 2.3 containers, but it still needs help from the container to load and initialize "unnamed" servlets (i.e. for tags) as far as I can tell. If only named servlets (specified in web.xml) are supported, I believe it can be done completely with the standard API for 2.3, using getNamedDispatcher() to get hold of an RD and then use wrapped request and response objects when it's invoked. 2.2 doesn't allow an RD to use wrapped request/response objects, so this approach doesn't work for 2.2 containers. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: [PROPOSAL] JSSI for Tomcat
Hans Bergsten typed the following on 19:17 10/12/2000 -0800 >But maybe I'm missing something. Are you saying the whole SSI processing >should be done as an interceptor instead of as a servlet? Is this something that could be done as a Servlet 2.3 Filter, and so be completely container independent for 2.3 containers? Kief --- bitBull makes the Internet bite: http://www.bitBull.com/demos/
Re: [PROPOSAL] JSSI for Tomcat
> 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. Yes, the documentation of tomcat3 is very bad... "Interceptor" is (or tries to be ) equivalent with an Apache module. Almost all of the tomcat's functionality ( parsing URLs, maps, authentication, class loaders, reloading, error handling - in 3.3, configuration, etc) is implemented in "modules" or "interceptors". In 3.3 we also implement server connectors ( HTTP, AJP ) as Interceptor - again mirroring a bit Apache ( and MPM ). The interceptor is a collection of hooks / notifications - for everything that happens in tomcat and for every functionality that is needed we have a hook, and people can define a module that will use that hook to implement the functionality in a particular way. In theory ( and what happens in Apache, IIS, NES ) all extensions should be implementable as modules ( + the core == a small set of classes representing common server objects ). JSSI is a good test case - from what I read I think we forgot one hook ( to notify when a new servlet is defined/added to the server - so that the JSSIInterceptor can implement isServletDefined ). Note that isServletDefined can be implemented either as a call to a component that manages servlets, or by maintaining a private structure (hashtable). The second choice is very important because it doesn't force a particular data structure for modules - the core can only use JDK1.1 tools, while a module can use JDK1.2 collections or specialized structures. Costin
Re: [PROPOSAL] JSSI for Tomcat
[EMAIL PROTECTED] wrote: > [...] > 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 :-) Okay. > > 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 initParams); 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 -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: [PROPOSAL] JSSI for Tomcat
> > 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
Re: [PROPOSAL] JSSI for Tomcat
Jeff Turner wrote: > > [...] > > That's a good idea, and jakarta-jsse is as good a name as any ;-) > > If I may be the first to throw cold water on that name.. JSSE already > stands for Java Secure Socket Extension > (http://java.sun.com/products/jsse/), which is necessary for Tomcat's SSL > support. Just imagine the confusion.. ;) I realized that as soon as I hit the Send button, and was just waiting for someone to react ;-) So how about jakarta-containerexts? I'm open to other suggestions, but let's not get too hung up on the name thing please. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: [PROPOSAL] JSSI for Tomcat
-- God made the integers; all else is the work of Man. -- Kronecker On Sun, 10 Dec 2000, Hans Bergsten wrote: > [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 ;-) If I may be the first to throw cold water on that name.. JSSE already stands for Java Secure Socket Extension (http://java.sun.com/products/jsse/), which is necessary for Tomcat's SSL support. Just imagine the confusion.. ;) [snip] --Jeff > Hans > -- > Hans Bergsten [EMAIL PROTECTED] > Gefion Software http://www.gefionsoftware.com > Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com >
Re: [PROPOSAL] JSSI for Tomcat
[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" th
Re: [PROPOSAL] JSSI for Tomcat
Hi Hans, > for tags and NCSA SSI directives, I decided to port Apache > JSSI to Tomcat. Now it's basically done for TC 3.2, and the question is > what to do with it ;-) > 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" :-) > 2) Support only for TC 3.2 initially +1 > 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 :-) 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. 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 :-) Costin
Re: [PROPOSAL] JSSI for Tomcat
Jon Stevens wrote: > on 12/9/2000 6:21 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> > wrote: > > > If it is Tomcat-specific, is there any reason it really needs to be a separate > > Jakarta project at all? Why not just absorb it into Tomcat? > > Problem with that in my eyes is that Tomcat is supposed to be the reference > implementation of the Servlet and JSP spec's, not of SSI. > Except that Tomcat already has "outside the spec" features up the kazoo, including your favorite (saving session state across server restarts :-). Even something mundane like serving static files or the invoker servlet is not part of the specification. What's the big deal about one more feature? > > -jon > Craig
Re: [PROPOSAL] JSSI for Tomcat
on 12/9/2000 6:21 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > If it is Tomcat-specific, is there any reason it really needs to be a separate > Jakarta project at all? Why not just absorb it into Tomcat? Problem with that in my eyes is that Tomcat is supposed to be the reference implementation of the Servlet and JSP spec's, not of SSI. -jon -- Honk if you love peace and quiet.
Re: [PROPOSAL] JSSI for Tomcat
"Craig R. McClanahan" wrote: > [...] > If it is Tomcat-specific, is there any reason it really needs to be a separate > Jakarta project at all? Why not just absorb it into Tomcat? > > In terms of CVS repositories, if the amount of version-dependent code is large it > would be easier just to put it in the existing version repositories as an > optional feature. If it's mostly independent with just a few links, a separate > CVS repository, under the auspices of the Tomcat project, seems to be much more > straightforward. There are a few reasons I suggested a separate Jakarta project: 1) Since it's optional, not part of the Servlet spec, and most likely of interest to less than the majority, keeping it in the main TC project just adds overhead (larger downloads, more to build, etc.) 2) Initially, it only supports TC 3.2. But 3.2 is in bugfix mode, so adding this as a new module (feature) in 3.2.1 doesn't seem right. 3) Except for a small amount of code that's needed to tie into the servlet container, it's independent from the various containers. I have not made any attempts to refactor the code yet, but the container interface could be a very simple class. It would then be easy to add interfaces to non-Tomcat containers as well. Keeping it as a separate project means that all improvements automatically applies to all supported containers. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: [PROPOSAL] JSSI for Tomcat
Jon Stevens wrote: > on 12/9/2000 3:55 PM, "Hans Bergsten" <[EMAIL PROTECTED]> wrote: > > > I know the migration of Java Apache projects has been discussed, but > > I have not seen a formal decision being made by PMC. So I like to > > run it by the PMC anyway, but based on what you say it sounds like it > > will not be any problem then. > > This has already been formalized and even advertised as happening. Look at > the Jakarta and Java Apache homepages as it clearly discusses this. > > In essence, I'm just trying to save everyone time here. > > > Another thing. If the migrated JSSI is supposed to continue to support > > JServ (sounds reasonable) > > No need to do that. > > >, maybe this should be called TSSI instead to > > avoid confusion (since it relies on TC internals and use TC package names). > > An alternative would be to keep the JSSI name but use TC package names and > > make it work with JServ as well as TC 3.2 in the initial version. Comments? > > +1 for TSSI. > If it is Tomcat-specific, is there any reason it really needs to be a separate Jakarta project at all? Why not just absorb it into Tomcat? In terms of CVS repositories, if the amount of version-dependent code is large it would be easier just to put it in the existing version repositories as an optional feature. If it's mostly independent with just a few links, a separate CVS repository, under the auspices of the Tomcat project, seems to be much more straightforward. > > -jon Craig
Re: [PROPOSAL] JSSI for Tomcat
on 12/9/2000 3:55 PM, "Hans Bergsten" <[EMAIL PROTECTED]> wrote: > I know the migration of Java Apache projects has been discussed, but > I have not seen a formal decision being made by PMC. So I like to > run it by the PMC anyway, but based on what you say it sounds like it > will not be any problem then. This has already been formalized and even advertised as happening. Look at the Jakarta and Java Apache homepages as it clearly discusses this. In essence, I'm just trying to save everyone time here. > Another thing. If the migrated JSSI is supposed to continue to support > JServ (sounds reasonable) No need to do that. >, maybe this should be called TSSI instead to > avoid confusion (since it relies on TC internals and use TC package names). > An alternative would be to keep the JSSI name but use TC package names and > make it work with JServ as well as TC 3.2 in the initial version. Comments? +1 for TSSI. -jon
Re: [PROPOSAL] JSSI for Tomcat
Jon Stevens 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. > > > > Note! This requires approval by the PMC, but I want to see what > > this group thinks about it before I make a proposal to the PMC. > > No approval by the PMC is necessary. This has already been voted on and > approved. It is part of the migration of Java Apache projects over to > Jakarta. I know the migration of Java Apache projects has been discussed, but I have not seen a formal decision being made by PMC. So I like to run it by the PMC anyway, but based on what you say it sounds like it will not be any problem then. Another thing. If the migrated JSSI is supposed to continue to support JServ (sounds reasonable), maybe this should be called TSSI instead to avoid confusion (since it relies on TC internals and use TC package names). An alternative would be to keep the JSSI name but use TC package names and make it work with JServ as well as TC 3.2 in the initial version. Comments? Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: [PROPOSAL] JSSI for Tomcat
on 12/9/2000 1:48 PM, "Hans Bergsten" <[EMAIL PROTECTED]> wrote: > After seeing a number of users on the TC user list asking about support > for tags and NCSA SSI directives, I decided to port Apache > JSSI to Tomcat. Now it's basically done for TC 3.2, and the question is > what to do with it ;-) > > If anyone is interested in this, I propose the following: > > 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. > > Note! This requires approval by the PMC, but I want to see what > this group thinks about it before I make a proposal to the PMC. No approval by the PMC is necessary. This has already been voted on and approved. It is part of the migration of Java Apache projects over to Jakarta. > 2) Support only for TC 3.2 initially > Since JSSI is dependent on the TC internals, it needs to be > adapted for each architecture. For instance, in TC 3.2 there's a > package named org.apache.tomcat.facade that is used by JSSI, but > in TC 3.3 the package is named org.apache.tomcat.facade2.2, and > in TC 4.0 facades are not used at all so a different integration > is needed. > > The current port works with TC 3.2. When the others get released, > the integration code can be factored out into a very small, pluggable > class. Having it be integrated in is fine. > 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 > > If you're positive to this proposal, I'll approach PMC about the new > subproject and try to get it set up ASAP. +1 Again, you don't need PMC approval because you already have it. -jon -- Honk if you love peace and quiet.
[PROPOSAL] JSSI for Tomcat
After seeing a number of users on the TC user list asking about support for tags and NCSA SSI directives, I decided to port Apache JSSI to Tomcat. Now it's basically done for TC 3.2, and the question is what to do with it ;-) If anyone is interested in this, I propose the following: 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. Note! This requires approval by the PMC, but I want to see what this group thinks about it before I make a proposal to the PMC. 2) Support only for TC 3.2 initially Since JSSI is dependent on the TC internals, it needs to be adapted for each architecture. For instance, in TC 3.2 there's a package named org.apache.tomcat.facade that is used by JSSI, but in TC 3.3 the package is named org.apache.tomcat.facade2.2, and in TC 4.0 facades are not used at all so a different integration is needed. The current port works with TC 3.2. When the others get released, the integration code can be factored out into a very small, pluggable class. 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 If you're positive to this proposal, I'll approach PMC about the new subproject and try to get it set up ASAP. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
