Hi,
since I've done now the needed rewrite of SGMLTag to support reading from
a Stream instead of a String containing the whole File (see commit a few
days ago to the whiteboard), I'd like to commit a Beta of the new
implementation soon to jserv_ssi.
Besides the reading from Stream (in fact, it's a java.io.Reader) I've
made some cleanups to JServSSI. Most of this has been done back in
december but I'd like to give an overview here again.
First, the old SSI-Servlet cached the result of the parsing process in
order to serve it fast, but the old implementation holds
the complete page in memory, splitted in parts, holding
'Servlet'-parts and 'String'-parts in a Vector .. needless to say that
this is only acceptable if there are not too much pages (less 1000)
because of memory usage.
I removed the String parts and only cache the servlet-parts now. Serving
of a page is done by reading the orignial page from disk, skipping the
servlet-parts which are filled by the output of the called servlets.
Performance-wise, this won't hurt much.
The second change is that I've separated the parsing of the Page
(org.apache.servlet.parse.PageParser), and the execution of the Servlet
(ServletTagHandler).
As a consequence of this separation it's possible to
register any TagHandlers (implementing the SpecialTagHandler interface) in
a PageParser-Servlet, so this can be used for a simple tag-based template
solution. The register-process associates a Tag-name with a handling class
(a SpecialTagHandler).
The new SSI-Servlet (which I've put into org.apache.servlet.SSI) is a
PageParser with a registered ServletTagHandler.
One of the reasons I've done this was that I wanted to propagate the
session-string within static pages using URL-rewriting (no, my
customer doesn't want to have Cookies) without the need of using JSP here
.. which creates a Servlet per page (ugs).
Now, its easy to register a TagHandler doing URL-rewriting for tags
named 'A' .. I've provided such a TagHandler (HREFParameterPropagator).
This Handler is registered in the servlet
org.apache.servlet.parse.ParameterPropagatingSSI (which behaves like a
normal SSI-servlet plus URL-rewriting) [.. and now you understand why I'd
like tho handle more than 1000 different pages going through this page...]
I also provided a simple ExampleTagHandler to show the ease of use.
Currently, you can find these classes in the whiteboard area; I am just
merging the latest changes from jserv_ssi into it
(SSIHttpServletResponse/SSIOutputStream).
Regarding the name of the servlet, I'd propose to put it in the package
org.apache.servlet.SSI
instead of
org.apache.jservssi.JServSSI
since it isn't dependant on JServ anymore but aims to be a general
SSI-implementation (I tested it successfully with JavaWebServer 1.1 and a
Beta of IBM Websphere which only had a PageCompile Servlet)
Following the naming 'rules' of the other Java Apache-Projects I'd propose
the name 'Java Apache SSI'.
ciao,
-hen
---
Henner Zeller [EMAIL PROTECTED]
PGP pub key [77F75B39]: finger [EMAIL PROTECTED]
"One difference between SuSE and Red Hat is that the former operates in a
country where people don't sue each other over coffee being too hot."
Linus Torvalds
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
