cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
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
> HTTP.

[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
development.

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
manage.

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
Xerces+Xalan+FOP+Batik.

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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message