Re: Integrating Cocoon (was: Access to Application ClassLoader froma Block?)

[Stefano Mazzocchi <st...@apache.org>]

Damn, I unsubscribed before reading this. Ok, taking care of it off list
(please, keep me copied)

Uli Mayring wrote:
> 
> On Sun, 25 Nov 2001, Michael McKibben wrote:
> 
> > Maybe I am missing something fundamental, but I don't see how using Cocoon
> > as a service violates IoC?
> 
> Well, I'm not the right person to answer this :)

I was the one who told Uli to be careful not to mess up IoC.
 
> > Cocoon naturally provides the Processor interface
> > as a service. The current CocoonServlet initializes the Cocoon component and
> > then delegates HTTP requests to the Cocoon Processor. My goal is to move the
> > initialization step to a block. 

This feature has been requested by many and I agree it's a good goal,
but I'm afraid you'd have to expose a bunch of internal Cocoon classes
to the outside in order for some block to call this block.

> > Then I would write a Servlet that looks up
> > the Processor and delegates the HTTP request ala CocoonServlet. Why do this?
> > Well, now I can deploy multiple wars in my Servlet container all using a
> > shared Cocoon component. 

Yes, I see this, or you could attach it to a Mailet to have your email
messages validated (could be useful for some B2B-over-SMTP
applications).

> > I could even use Cocoon from a MessageDriven EJB.
> > This is the idea anyways. Hopefully it works in practice.
> 
> If I understand you correctly, you still have a single entry-point (HTTP)
> and therefore I believe you don't violate IoC.

It doesn't have to be HTTP, but yes, it's a single entry-point and
doesn't violate IoC.
 
> > I believe the advice given to you by cocoon-dev was to not call
> > sub-components of Cocoon (i.e. components defined in cocoon.xconf and the
> > sitemap.) Of course you have to call into the Cocoon Processor, otherwise,
> > how would you use it! Requests have to get passed into Cocoon somehow :)
> 
> My idea was to have better granularity at the service level, not just one
> big "Cocoon service", so every application that needs parts of Cocoon's
> functionality can simply get a hold of the specific blocks it needs.

Once Carsten moves Cocoon's general XML components into avalon, you can
easily obtain this.
 
> Going over HTTP means you need a webserver, a document repository at
> the webserver's location and a (potentially costly) HTTP connection every
> time you have a request, plus you need to go through the whole processing
> pipeline every time, even if you know from the start where you want to go.

This is not what I perceived he wants to do.

> Instead, since my applications run under Phoenix anyway, I could use the
> functionality directly, if it were available in Phoenix-friendly form,
> e.g. as a block.

> Anyway, one argument in the discussion was that for such simple tasks I
> should write a wrapper around Xalan or fop and not use Cocoon at all,
> because it is meant for more complex processing. So that is the route I'm
> going at the moment, even though I believe my system will become more
> complex with time, too. Also I need Cocoon for the frontend anyway, so
> there's some duplication of efforts. It would be better if I could use the
> same Cocoon engine in my backend apps and in the browser-based frontend.
> Well, you're never too old to learn, so perhaps one of these days I see
> the light :)

The Cocoon engine is already decoupled from the servlet code. There is
nothing Servlet-based inside Cocoon, the entire Environment was
abstracted to allow command line interface. Making Cocoon.class an
avalon block is piece of cake and it removes the need for setting up the
HTTP request, as you are asking.

This is what has been proposed in this thread.

And this doesn't violate IoC, even if it needs to expose a bunch of
Cocoon classes in the block interface so it might turn out to be a
complex service to call as a block, but it's indeed possible and useful
in some special cases.

Moreover, once the general Cocoon components are moved into Avalon, you
have the ability to do both: call Cocoon as a block without having to go
thru HTTP or use the XML functionalities Cocoon builds upon to power
your own avalon-aware logic.

Hope this 'finally' shades some light on this.

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



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>