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 HTTP. Ulrich -- Ulrich Mayring DENIC eG, Systementwicklung --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
