You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Rob Nikander <ni...@mindspring.com> on 1999/11/27 20:27:03 UTC
Servlet chaining?
Is it possible to do servlet chaining with Tomcat? If so, how?
Thanks,
Rob
Re: Servlet chaining?
Posted by jon * <jo...@clearink.com>.
on 12/1/99 3:08 PM, Craig R. McClanahan <cm...@mytownnet.com> wrote:
> For all intents and purposes, that's exactly how JSP engines can work, as
> well -- with the added ability to avoid class loader problems because they
> can generate their own class names.
This is how I intend to have Turbine work as well. Screens can easily be
written to call any other servlets...including JSP generated servlets. ;-)
FYI, I do this with Turbine all the time...essentially a "Screen" is just a
servlet with a single argument passed into it...a RunData object...in this
object is a copy of Req/Res as well as other information. "Screen"/module
reloading (and caching!) works just fine.
-jon
Re: Servlet chaining?
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
jon * wrote:
> on 11/30/99 3:13 PM, Ben Laurie <be...@algroup.co.uk> wrote:
>
> > a) That's a pretty narrow view of the way the real world works - often
> > the behaviour of the previous servlet is entirely out of your control.
>
> how so? It is possible to do this:
>
> Class.forName("commercialservlet").newInstance();
>
> Passing in your own HttpServletRequest/Response objects gives you control
> over the output the same way that chaining would.
>
For all intents and purposes, that's exactly how JSP engines can work, as
well -- with the added ability to avoid class loader problems because they
can generate their own class names.
>
> -jon
>
Craig McClanahan
Re: Servlet chaining?
Posted by James Duncan Davidson <ja...@eng.sun.com>.
jon * wrote:
> anyways, just because jason gives that suggestion, it doesn't mean that it
> is necessarily the right way to do things. ;-) it is just a
> suggestion...take it as that...i see the above thing as a horrible hack. ;-)
And, in the time since Jason wrote that, he's pretty much seen that it's
a bad thing as well.
--
James Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do()
Re: Servlet chaining?
Posted by Jason Hunter <jh...@acm.org>.
jon * wrote:
> anyways, just because jason gives that suggestion, it doesn't mean
> that it is necessarily the right way to do things. ;-) it is just a
> suggestion...take it as that...i see the above thing as a horrible
> hack. ;-)
Righto. Servlet chaining was a nifty feature that the Java Web
Server and many other servers supported (and still support). Deblink
is a useful server-independent demonstration of that feature. After the
book went to press, Sun decided that Chaining as it existed in JWS was
too hacky and then when they came out with the first official servlet
specification for API 2.1 they made sure chaining was not in there.
Because of that, the JServ team decided then that they wouldn't
implement it.
We may see chaining again, but not in its previous form. It'll probably
be called Filtering and the components doing the filtering will not be
servlets. In fact, it may end up like the Apache rewrite module, only
done in the Servlet API so it's portable.
-jh-
Re: Servlet chaining?
Posted by jon * <jo...@clearink.com>.
on 12/1/99 5:38 PM, Rob Nikander <ni...@mindspring.com> wrote:
> I originally asked a question about Servlet chaining because I was reading
> the O'Reilly Servlet book and it mentioned the topic in there. I haven't
> gotten too far into that book, but the example demonstrated the use of
> servlet chaining as a sort of filter. He sat up the web server to pass all
> *.html pages through a servlet that removed <blink> tags.
> Possibly, you could set the server up to filter responses through a series
> of servlets. This would allow you to change the behavior of your web site
> just by "plugging" in different servlets, rearranging the order, etc -- not
> touching code.
there is no reason why you can't already do this with Apache and without
using chaining...
Simple solution...mod_rewrite + servlets that read the file into memory and
simply filter the files. you could even do caching of the page content as
well as doing a proxy that grabbed content from other servers.
anyways, just because jason gives that suggestion, it doesn't mean that it
is necessarily the right way to do things. ;-) it is just a
suggestion...take it as that...i see the above thing as a horrible hack. ;-)
-jon
Re: Servlet chaining?
Posted by Rob Nikander <ni...@mindspring.com>.
jon * wrote:
> on 11/30/99 3:13 PM, Ben Laurie <be...@algroup.co.uk> wrote:
>
> > a) That's a pretty narrow view of the way the real world works - often
> > the behaviour of the previous servlet is entirely out of your control.
>
> how so? It is possible to do this:
>
> Class.forName("commercialservlet").newInstance();
>
> Passing in your own HttpServletRequest/Response objects gives you control
> over the output the same way that chaining would.
>
> -jon
>
I originally asked a question about Servlet chaining because I was reading
the O'Reilly Servlet book and it mentioned the topic in there. I haven't
gotten too far into that book, but the example demonstrated the use of
servlet chaining as a sort of filter. He sat up the web server to pass all
*.html pages through a servlet that removed <blink> tags.
Possibly, you could set the server up to filter responses through a series
of servlets. This would allow you to change the behavior of your web site
just by "plugging" in different servlets, rearranging the order, etc -- not
touching code.
Rob
Re: Servlet chaining?
Posted by Stefano Mazzocchi <st...@apache.org>.
costin@dnt.ro wrote:
>
> > 1) Servlet chaining sucks, it's not portable and should be avoided.
> > 2) RequestDispatcher doesn't fit all componentization needs.
> > 3) Servlet piping is possible only with _lots_ of complex machinery
> > between servlets and may severely impact performance and portability.
>
> In general - the communication between components is a difficult problem.
> Some problems do not have simple solutions - and piping can solve
> only simple problems of communication.
>
> RequestDispatcher is a good solution for the problem it solves - including
> or forwarding of servlets. Chaining sucks - and it have all the
> limitations of unix pipes. "Complex machinery" for servlet piping may work
> in particular situations, but it will suck as performance or generality.
>
> What about _not_ trying to use servlets instead of Objects and piping
> instead of method invocation ( or message passing or any other form
> of communication ). Having one component to write it's data as text ( be
> it XML ) - and the next one parse it and write it as text to the next one
> - that's a _very_ bad design, regardless of what the servlet engine
> provides.
Tell them, brother! That is the _exact_ reason why Cocoon exists :)
But you don't know how many people turned their back on Cocoon because I
said the exact above words when they wanted their XML-producing servlets
to be postprocessed by Cocoon.
Cocoon defines it's own producing components, called as you would expect
"producers", and passes them thru a pipeline of processing components
called "processors" and then formats it using a "formatter".
The people who understand this is _totally_ happy, they threw away
Servlet.java and use Producer.java. there is also a producer-wrapper
that turns your producer into real servlets for stand-alone operation
without Cocoon in between.
Well, doesn't matter how hard you try, but the users want to use
servlets as producing components. Which is clearly a pain in the ass in
some situations and it's _much_ slower.
But they don't get it and they are also afraid of using "proprietary"
extentions which don't exist on .
Gee, tell me, how silly is that? Cocoon is a servlet, it's free and it's
91Kb in size. Those are _serious_ limitations, man... NOT!!!
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
Re: Servlet chaining?
Posted by co...@dnt.ro.
> 1) Servlet chaining sucks, it's not portable and should be avoided.
> 2) RequestDispatcher doesn't fit all componentization needs.
> 3) Servlet piping is possible only with _lots_ of complex machinery
> between servlets and may severely impact performance and portability.
In general - the communication between components is a difficult problem.
Some problems do not have simple solutions - and piping can solve
only simple problems of communication.
RequestDispatcher is a good solution for the problem it solves - including
or forwarding of servlets. Chaining sucks - and it have all the
limitations of unix pipes. "Complex machinery" for servlet piping may work
in particular situations, but it will suck as performance or generality.
What about _not_ trying to use servlets instead of Objects and piping
instead of method invocation ( or message passing or any other form
of communication ). Having one component to write it's data as text ( be
it XML ) - and the next one parse it and write it as text to the next one
- that's a _very_ bad design, regardless of what the servlet engine
provides.
Costin
Re: Servlet chaining?
Posted by Stefano Mazzocchi <st...@apache.org>.
Ben Laurie wrote:
>
> jon * wrote:
> >
> > on 11/30/99 3:13 PM, Ben Laurie <be...@algroup.co.uk> wrote:
> >
> > > a) That's a pretty narrow view of the way the real world works - often
> > > the behaviour of the previous servlet is entirely out of your control.
> >
> > how so? It is possible to do this:
> >
> > Class.forName("commercialservlet").newInstance();
> >
> > Passing in your own HttpServletRequest/Response objects gives you control
> > over the output the same way that chaining would.
>
> You can control _where_ it outputs, but not what or how, surely?
Ben is right. What Jon is proposing doesn't cover all possible cases and
might be the reason why Turbine and Cocoon cannot be connected unless a
better "piping" model is added to the servlet API.
People, listen up, this will be vital in the future when you'll need
dynamic XML creation and server side handling.
Jon proposes to pass on your request/respone stuff to your dynamically
linked servlet. This may be called "servlet componentization", since
this follows a "componentizable" pattern.
Note, the called servlet will act for you and will trigger output method
generation thru the given objects.
Two cases:
1) the req/res are the exact same the servlet engine gave you ---> this
means the called servlet is working for you at your place. The generated
output gets included into your output. Your calling servlet is NOT able
to touch it, not even to be aware of what was generated.
2) the req/res are "virtual" in the sense that you created your own that
partially wrap around the servlet engine instances, and implement other
methods. ---> this would allow the servlet to work on the generated
output and do, for example, transformations.
Suppose you have Turbine (which is a servlet) calling Cocoon (which is a
servlet) which calls a JSP (which is compiled as a servlet) which
generates a 100Mb database report in XML. Cocoon should then
XSL-transform it to a PDF database report.
The Servlet API does -NOT- allow you to "filter" the output of another
servlet. Period. To do that, you need to do a bunch of machinery which
most of the time involves complex handling of pipes and streams, mostly
requiring two threads of execution, complex concurrency management and
such. A real pain in the ass.
True, the above is considered a _very_ complex web application
framework, but we clearly see the Servlet API as a platform for creating
complex web frameworks, rather than stupid snoopservlet stuff, as much
as the Java API is for complex programs rather than hello world comman
line apps.
So, at the end a few points should be clear:
1) Servlet chaining sucks, it's not portable and should be avoided.
2) RequestDispatcher doesn't fit all componentization needs.
3) Servlet piping is possible only with _lots_ of complex machinery
between servlets and may severely impact performance and portability.
Note: Jasper is a very special case where this piping is simple. RD was
created exactly for this.
But JSP are already hittin the hard walls of this limitations: ever used
JSP for XML dynamic generation?
Well, then you know what I mean :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
Re: Servlet chaining?
Posted by Ben Laurie <be...@algroup.co.uk>.
jon * wrote:
>
> on 11/30/99 3:13 PM, Ben Laurie <be...@algroup.co.uk> wrote:
>
> > a) That's a pretty narrow view of the way the real world works - often
> > the behaviour of the previous servlet is entirely out of your control.
>
> how so? It is possible to do this:
>
> Class.forName("commercialservlet").newInstance();
>
> Passing in your own HttpServletRequest/Response objects gives you control
> over the output the same way that chaining would.
You can control _where_ it outputs, but not what or how, surely?
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Servlet chaining?
Posted by jon * <jo...@clearink.com>.
on 12/2/99 8:19 AM, Brill Pappin <br...@jmonkey.com> wrote:
> The trouble with that, is that the servlet is out of context with the
> Servlet Engine... not a good thing...
>
In JSDK 2.0, there was getServlet(). In JSDK 2.1 and higher there are other
methods for getting access to other servlets running in the engine.
That is the solution you are looking for.
-jon
Re: Servlet chaining?
Posted by Brill Pappin <br...@jmonkey.com>.
The trouble with that, is that the servlet is out of context with the
Servlet Engine... not a good thing...
- Brill Pappin
www.jmonkey.com
The sooner you fall behind,
the more time you will have
to catch up."
----- Original Message -----
From: jon * <jo...@clearink.com>
To: <ge...@jakarta.apache.org>
Sent: Wednesday, December 01, 1999 4:36 PM
Subject: Re: Servlet chaining?
> on 11/30/99 3:13 PM, Ben Laurie <be...@algroup.co.uk> wrote:
>
> > a) That's a pretty narrow view of the way the real world works - often
> > the behaviour of the previous servlet is entirely out of your control.
>
> how so? It is possible to do this:
>
> Class.forName("commercialservlet").newInstance();
>
> Passing in your own HttpServletRequest/Response objects gives you control
> over the output the same way that chaining would.
>
> -jon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
Re: Servlet chaining?
Posted by jon * <jo...@clearink.com>.
on 11/30/99 3:13 PM, Ben Laurie <be...@algroup.co.uk> wrote:
> a) That's a pretty narrow view of the way the real world works - often
> the behaviour of the previous servlet is entirely out of your control.
how so? It is possible to do this:
Class.forName("commercialservlet").newInstance();
Passing in your own HttpServletRequest/Response objects gives you control
over the output the same way that chaining would.
-jon
Re: Servlet chaining?
Posted by Ben Laurie <be...@algroup.co.uk>.
"Craig R. McClanahan" wrote:
>
> Rob Nikander wrote:
>
> > Is it possible to do servlet chaining with Tomcat? If so, how?
> >
> > Thanks,
> > Rob
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
>
> If you are speaking of having one servlet post-process the output of
> another, this is not possible with Tomcat. IMHO it is also not a good
> design technique -- the previous elements of the chain should be normal
> Java objects with output methods, rather than being servlets.
Hmm.
a) That's a pretty narrow view of the way the real world works - often
the behaviour of the previous servlet is entirely out of your control.
b) One of the driving forces behind Apache 2.0 is providing exactly this
facility.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Servlet chaining?
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Rob Nikander wrote:
> Is it possible to do servlet chaining with Tomcat? If so, how?
>
> Thanks,
> Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
If you are speaking of having one servlet post-process the output of
another, this is not possible with Tomcat. IMHO it is also not a good
design technique -- the previous elements of the chain should be normal
Java objects with output methods, rather than being servlets.
Craig McClanahan