tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eduardo Pelegri-Llopart <>
Subject Re: [Fwd: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container]
Date Tue, 04 Jan 2000 00:50:55 GMT
I have not looked to Craig's proposal (in my printer now), but I share
the inclination of making some notion of filtering part of the platform,
with the ability of processing incoming requests and outgoing responses.

FWIW, OMG uses the term "interceptor" for something similar, in the
context of IIOP invocation, if I remember correctly (their web site - - was only partially responding).  Since IIOP is also part
of J2EE, it may be worth using another term; I have not looked at
Craig's description well enough to make a suggestion yet.

	- eduard/o

Ricardo Rocha wrote:
> > Ricardo Rocha wrote:
> > > Provided they're given "write-access" to the servlet
> > > response, do you see XSLT postprocessing as inside
> > > the realm of interceptors' purpose in life?
> > >
> Craig McClanahn wrote:
> > If the community at large thinks that this kind of
> > post-processing should indeed be embedded in the
> > engine itself (I've personally felt that this should be
> > handled at the application level, inside a servlet
> > like Cocoon, but I haven't looked deeply at what that
> > means either), then yes, it is definitely within the purpose
> > in life of Interceptors. Because you can attach an
> > Interceptor to any container you like, you can easily
> > impose the post processing (and pay the corresponding
> > overhead price) only on the output from a particular
> > servlet, or the servlets of a particular web application.
> Yes, Cocoon already provides (excellent!) application-level
> support for servlet-based XML/XSLT web publishing.
> However, there seems to be a certain degree of "friction"
> between Cocoon's DOM-based processing model and that
> of stream-oriented servlets and JSP.
> Even as Cocoon embraces [stream-oriented] SAX it seems
> that the servlet architecture as such needs to be extended
> to better accommodate XML processing in general.
> Under these circumstances, a "response-writing" interceptor
> looks certainly appealing!
> Why so? Why embed XSLT post-processing in the engine
> itself instead of at the application-level? How does this
> relate to the fact that XSLT processing is recognized
> as relevant in the JSP spec but its support has not been
> addressed yet?
> Let's consider the case where we want our servlet/JSP
> application to generate XML, instead of "raw" HTML.
> We know this is desirable for the usual, well-known
> reasons: achieving "true" separation of content and
> presentation, making JSP page authoring accessible
> to non-programmers by means of tag libraries and
> application-oriented markup vocabularies, generating
> presentation markup in a browser and device-independent
> fashion, generating portable DHTML, etc, etc...
> Obviously, this servlet/JSP-based XML generation
> demands XSLT post-processing. This, in turn, imposes
> a penalty in terms of additional processing load.
> Let's recall here that XSLT processing may take place
> at either the server _or_ the client side. Thus, whenever
> possible, we want to offload XSLT processing to the
> client.
> Not all browsers support XSLT, though (in fact, only one
> does right now!) so the server must still be capable of
> providing such processing.
> How do we achieve this without requiring our servlets and
> JSP pages to be concerned about how XSLT processing
> takes place?
> It looks like an interceptor could do a terrific job here:
> given the request's user-agent it would decide whether to
> transcribe response output verbatim or post-process it by
> applying an XSLT stylesheet. (Again, this is based on the
> assumption that XSLT processing is stream-based, SAX)
> > The reason that write access is an issue in the proposed
> > architecture is that the Response implementation is actually
> > provided by the communications adapter through which the
> > request was received.  It is the adapter-supplied logic that
> > implements ServletOutputStream that will be oblivious to the
> > need for the extra buffering, and that's the design issue
> > that needs to be dealt with.
> Yes, this is at the core of the "servlets limitations for xml
> processing" discussion. It's clear we badly need an extra
> layer between servlet-level response output manipulation
> and actual network communication.
> > Of course, any such use of Interceptors for post
> > processing will be Tomcat specific, because it is
> > not part of the standard servlet API. However,
> > successful use of Interceptors for this might
> > motivate the inclusion of similar concepts in the
> > standard in some future version.
> I sincerely hope this is the case! The Servlet API would
> really benefit from a revision that better accommodates
> XML processing.

View raw message