You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Robin Green <gr...@hotmail.com> on 2000/09/16 00:15:04 UTC
How to Call Servlets, CGIs on your server and other servers; Servlet Chaining
A lot of people have asked about this recently. It's really SO SO simple
(and it's going in the new FAQ which is effectively a rewrite).
Unfortunately the 'answer' (or lack thereof) given in the current FAQ about
"servlet chaining" is either very misleading or just plain wrong, I don't
know which. Stefano?
What you DON'T do is use ProducerFromRequest - that's a security risk, as
noted in the recent Security Advisory which I can email to anyone who wants
it (it's also in the mail archives).
[A]. If the servlet or whatever you're calling returns XML, you can just do
this: (If not see [B] below).
1. Get the latest Cocoon from xml.apache.org/from-cvs or just from CVS
directly. 1.7.4 and below have a bug which prevents this from working.
2. Make an XSP page like this:
<?cocoon-process type="xsp"?>
<xsp:page xmlns:xsp="http://www.apache.org/1999/XSP/Core"
xmlns:util="http://www.apache.org/1999/XSP/Util">
<page>
<util:include-uri href="http://myserver.com/servlets/foo"/>
</page>
</xsp:page>
To build the URL dynamically just do something like this (if I remember
correctly):
<util:include-uri>
<util:href><xsp:expr>"http://myserver.com/servlets/foo?x=" + request.
getParameter ("foo")</xsp:expr></util:href>
</util:include-uri>
To include static XML files you can even use <util:include-file> (which is
faster), but only if the file is on the filesystem(s) of your server. There
are other options like XInclude and XML entities, but these should work
fine.
[B] To get data from non-XML sources, just do like in any Java program:
Object content = new URL ("http://myserver.com/foobar").getContent ();
or openStream(), or whatever is most appropriate (inside a Producer or
preferably an XSP page). Read the Javadocs for Java - it pays dividends!
To include static non-XML files which exist on your own server, it's faster
to just do as A above but replace util:include-uri href= with
util:get-file-contents name=
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
Re: How to Call Servlets, CGIs on your server and other servers; Servlet
Chaining
Posted by Stefano Mazzocchi <st...@apache.org>.
Robin Green wrote:
>
> A lot of people have asked about this recently. It's really SO SO simple
> (and it's going in the new FAQ which is effectively a rewrite).
>
> Unfortunately the 'answer' (or lack thereof) given in the current FAQ about
> "servlet chaining" is either very misleading or just plain wrong, I don't
> know which. Stefano?
>
> What you DON'T do is use ProducerFromRequest - that's a security risk, as
> noted in the recent Security Advisory which I can email to anyone who wants
> it (it's also in the mail archives).
>
> [A]. If the servlet or whatever you're calling returns XML, you can just do
> this: (If not see [B] below).
>
> 1. Get the latest Cocoon from xml.apache.org/from-cvs or just from CVS
> directly. 1.7.4 and below have a bug which prevents this from working.
>
> 2. Make an XSP page like this:
>
> <?cocoon-process type="xsp"?>
> <xsp:page xmlns:xsp="http://www.apache.org/1999/XSP/Core"
> xmlns:util="http://www.apache.org/1999/XSP/Util">
> <page>
> <util:include-uri href="http://myserver.com/servlets/foo"/>
> </page>
> </xsp:page>
>
> To build the URL dynamically just do something like this (if I remember
> correctly):
>
> <util:include-uri>
> <util:href><xsp:expr>"http://myserver.com/servlets/foo?x=" + request.
> getParameter ("foo")</xsp:expr></util:href>
> </util:include-uri>
>
> To include static XML files you can even use <util:include-file> (which is
> faster), but only if the file is on the filesystem(s) of your server. There
> are other options like XInclude and XML entities, but these should work
> fine.
>
> [B] To get data from non-XML sources, just do like in any Java program:
>
> Object content = new URL ("http://myserver.com/foobar").getContent ();
>
> or openStream(), or whatever is most appropriate (inside a Producer or
> preferably an XSP page). Read the Javadocs for Java - it pays dividends!
>
> To include static non-XML files which exist on your own server, it's faster
> to just do as A above but replace util:include-uri href= with
> util:get-file-contents name=
Yes, your answer is much better than the one in the FAQ... I think we
should update it.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: How to Call Servlets, CGIs on your server and other
servers;ServletChaining
Posted by Ulrich Mayring <ul...@denic.de>.
Per Kreipke wrote:
>
> Uli,
>
> Can you share this code with the rest of us?
Sure, find it in the attachment. You'll also need
ProducerFromRequest.java and CocoonServletRequest.java from the standard
cocoon distribution. And make sure no-one unauthorized can access this
servlet.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
RE: How to Call Servlets, CGIs on your server and other servers;Servlet Chaining
Posted by Per Kreipke <pe...@onclave.com>.
Uli,
Can you share this code with the rest of us?
> On Fri, 15 Sep 2000, Robin Green wrote:
>
> > What you DON'T do is use ProducerFromRequest - that's a
> security risk, as
> > noted in the recent Security Advisory which I can email to
> anyone who wants
> > it (it's also in the mail archives).
>
> I've taken what used to be the ProducerFromRequest code and stuffed it
> into a new class and made a servlet out of it. That way I can post an XML
> doc to this servlet and it passes the XML doc on to cocoon, which delivers
> the result directly to the client, i.e. not going through the servlet
> again on the way back.
>
> This is a very simple solution if you have several apps communicating with
> each other via XML. Of course you can use SOAP for this, but it is a bit
> overkillish in my mind. Our internal apps simply communicate via XML and
> the servlet and cocoon are the mediators, if the XML sent by one app needs
> to be transformed first, before sending it to the other app.
>
> For example, we have an app producing its results in XML and we can send
> the XML to cocoon and get back a PDF with the result nicely formatted for
> archival and printing.
>
> Ulrich
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
Re: How to Call Servlets, CGIs on your server and other servers;
Servlet Chaining
Posted by Uli Mayring <ul...@denic.de>.
On Fri, 15 Sep 2000, Robin Green wrote:
> What you DON'T do is use ProducerFromRequest - that's a security risk, as
> noted in the recent Security Advisory which I can email to anyone who wants
> it (it's also in the mail archives).
I've taken what used to be the ProducerFromRequest code and stuffed it
into a new class and made a servlet out of it. That way I can post an XML
doc to this servlet and it passes the XML doc on to cocoon, which delivers
the result directly to the client, i.e. not going through the servlet
again on the way back.
This is a very simple solution if you have several apps communicating with
each other via XML. Of course you can use SOAP for this, but it is a bit
overkillish in my mind. Our internal apps simply communicate via XML and
the servlet and cocoon are the mediators, if the XML sent by one app needs
to be transformed first, before sending it to the other app.
For example, we have an app producing its results in XML and we can send
the XML to cocoon and get back a PDF with the result nicely formatted for
archival and printing.
Ulrich