tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eduardo Pelegri-Llopart <Eduardo.Pelegrillop...@eng.sun.com>
Subject Re: [Fwd: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container]
Date Tue, 04 Jan 2000 01:36:46 GMT
Right, if the concepts are close enough then I agree one can reuse the
term as you do in your paragraph: tomcat interceptor, iiop interceptor. 
And, when the context is clear enough one can just talk about
"interceptor".

The situation is the same with containers, but a bit different with
components, since we have given a specific name to most (all?) of the
components we have: Servlets, JSPs, JavaBeans, EJBs.

Thaks,

	- eduard/o

Assaf Arkin wrote:
> 
> OMG indeed is using an Interceptor that can affect the outcome of a
> remote invocation. The design pattern is similar to Craig's
> interceptors, it can extend the invocation (e.g. by adding transaction
> context), block it (e.g. security) or change it (e.g. by redirecting).
> Like Tomcat interceptors, OMG interceptors are not part of the
> application but part of the environment and can be plugged into the ORB
> to enhance it's functionality, but applications are not dependent/aware
> of them.
> 
> Since both IIOP and Tomcat Interceptors fulfill the exact same design
> pattern, there is full justification for using the same name, just like
> both Servlet and EJB are termed containers and use Sessions, even though
> the APIs are totally separate,
> 
> arkin
> 
> Eduardo Pelegri-Llopart wrote:
> >
> > 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 -
> > www.omg.org - 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.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Mime
View raw message