cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <>
Subject Re: Jo! & WAR file apps
Date Fri, 02 Nov 2001 12:08:41 GMT
Paul Hammant wrote:
> Err, are we not talking baout mounting Cocoon inside Jo inside Phoenix?

[Cc: to cocoon-dev list]

Normally the webserver has to parse the request and then, after
determining that the request is for the servlet engine, make a TCP/IP
connection to it and pass the request on. The connection is a costly
operation, even if on the same host. Then, the servlet engine needs to
parse the request again in order to determine which servlet is
responsible for it. In Jo's case the webserver can talk directly to the
servlet engine, as they are one application. The servlet engine itself
never makes a TCP/IP connection, it just starts a servlet in the same
JVM. Now I can think of several possibilities:

1) Instead of starting a servlet, make Jo call various Cocoon-blocks
(which implement Callable or somesuch interface)
2) Have Jo call a dispatcher servlet, that can then call the various
Cocoon-blocks and also use other Avalon-Blocks.
3) Install Cocoon as a .war application under Jo.

The third option is the easiest to implement, but you can only use
Cocoon as a monolithic application and you cannot access it without a
costly HTTP connection, even if you are in the same JVM.

The first option requires changes in Jo and I don't think the Jo
developer wants to introduce proprietary Phoenix connectors.

So the second option seems to be best. It has the advantage that you
only need to go over Jo and the Dispatcher servlet, when requests come
in via HTTP from outside users. If you have a .sar application under
Phoenix, then it can use the Cocoon-blocks directly.

For example, we have a lot of asynchronous requests, which come in via
email. They are stored in a MessageQueue and processed by various .sar
applications. The result of the transaction is sent out via email again
- it would be nice, if I could attach a dynamically generated PDF. So
for that I'd like to have a "XML-->XSL(T|FO)" block, I probably don't
care much about XSP, the Sitemap, generators and all the other bells and
whistles Cocoon has. But the same block could also be used to serve
dynamically generated PDFs to synchronous connections coming in over


Ulrich Mayring
DENIC eG, Systementwicklung

To unsubscribe, e-mail:
For additional commands, email:

View raw message