cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Jo! & WAR file apps
Date Sat, 03 Nov 2001 11:31:47 GMT
Ulrich Mayring wrote:
> 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

[sorry for crossposting, but this interests both communities, I think]

One question: you want to remove the connection overhead in order to
obtain Cocoon services and I agree that this is a "good thing"(tm).
Originally, Pier and I designed Cocoon2 to be an avalon block but
decided to move away from that since the APIs weren't solid enough.

Now, this said, please reread the above sentence: the key part is
"obtain cocoon services".

Cocoon is, like it or not, based on a request/response paradigm that is
modelled after HTTP.

Sure, the environment is abstract and I still believe that a Mailet
interface can be written around Cocoon to provide XML-based mail
handling capabilities of some sort, but we decided to focus on web

So, my vision is that if you want "XML --> XSL(T|FO)" processing block,
you are going to create a behavioral interface that doesn't ask for a
particular Cocoon resource, but pushes the various streams into the
service and wants to obtain a result.

This is what we call "Subversion of Control"!

And it's evil since it twistes a bood IoC design in such a way that it
becomes a nightmare for users to understand and for developers to

So, my vote to the proposal "would you like to add block-like behavior
to Cocoon" is *heavily* dependent on what you want this block interface
to be.

If you want to model IoC behavior, then +1.

If you want some XML processing API, then -1.

There are people that believe that Cocoon can be turned into a service
and maintain its architectural efficiency and elegant design (i.e. the
Turbine people that say they support Cocoon just because they use it as
a XSLT tranformer!).

I simply do not and for the reason above: IoC means that you ask for a
resource to Cocoon and it knows what to do.

This is a design pattern that must not be altered in any way, under any
circumstance or Cocoon will be nothing different from

I hope you guys understand my strong feelings about IoC.

If not so, please, make yourself heard because it's vital that we all
agree on something so basic.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

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

View raw message