cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] Another step to blocks: Application container support
Date Fri, 11 Mar 2005 19:19:25 GMT
Just one clarification: I want to leave the core as it is, we use our
container and all the code we provide in the core is free of any other
container (apart from the glue code mentioned below)


Carsten Ziegeler wrote:
> At the last GT we agreed that our core should not depend on other
> projects, so we wrote our own container and did not use an existing one.
> We also said that on the application level, a user can use whatever
> container she wants on top of Cocoon.
> It seems that this is a good choice, as we don't redo the work already
> done in the container area in other projects and on the other hand we
> are free to do what we want/need in the core.
> Compared to other solutions out there, our container (avalon based) is
> not state of the art anymore. Other projects like Spring or Hivemind
> have far better features and help in rapid development of component
> based applications. In addition using POJOs is very famous in our days.
> So for real applications you will end up using a different solution,
> being it Spring or Hivemind or whatever - I don't want to drive a
> discussion here about which project of the two is the better one. So I
> just mention both of them and refer to them in the following text just
> by DCC (=different component container).
> Now, I think we should help users in doing this. I'm currently thinking
> about directly supporting DCC on the application level and therefore
> creating support for an "application container" (We can later on
> decide if we support both, or just one of them or a totally different one.)
> With the latest additions to the trunk we nearly have the most important
> features of blocks already implemented - and that without really having
> a block as an object/component. Currently the sitemap is the central
> point for an application: you can include xconfs, define an own
> classpath etc.
> Currently I see the need for two additional features:
> a) "a request listener" - I want to be able to act on each request
> comming into my sitemap; and in addition I would like to do something
> when the request is finished which means *after* the serializer wrote
> the content into the stream. Now, doing something on each request *can*
> be done by using actions or some flow script; but actions can't be run
> after the serializer and it's a lot of overhead to use flow script for
> each and every request.
> We already have a listener, but unfortunately this is tied to the
> processor. So you can only have one listener for every request entering
> Cocoon - but not on a per sitemap level.
> b) Direct support for DCC. Using these frameworks is not that difficult
> inside Cocoon, but I think it could be easier.
> What do you think if e.g. a "getComponent("something")" in flow uses a
> Spring BeanFactory (and if the factory does not have the bean/component
> then the usual Avalon mechanism is used). The same would happen if you
> get a service manager from the Cocoon core.
> We could tie this to a sitemap as well, so you can have different
> configured DCC containers running inside Cocoon - for each
> application you're running inside Cocoon an own one. (Don't know if this
> is possible with DCC, but I guess so). So there are two differences to
> using DCC without explicit Cocoon support: a) the usual Cocoon mechanism
> for components (lookup/getComponent) works as well and b) you can have
> different applications with different DCC configurations. In addition
> they are shielded by own classloaders!
> We could extend this and add some additional glue code that makes core
> Cocoon features (like the Context, settings etc.) available to the DCC.
> With these additions we get kind of a "sitemap controller" (or
> whatever we call it): component configurations (xconf), DCC support,
> class loading, listeners etc. This sitemap controller could become later
> on the "block logic" or the block object/component.
> While a) is easy to implement and does not really have an impact, b) is
> imho the glue to support rapid application development with Cocoon even
> more - just tell Cocoon that you want to use your favorite DCC framework
>  via the sitemap and Cocoon sets up everything for you.
> We could either start adding these additional things into the sitemap
> (like we did with class loading and configurations) or we could think
> about using an additional configuration file that is optional and lies
> in the same directory as a sitemap. This file could be the start for a
> block descriptor. I personally don't care which way we choose as a
> start, although I think adding this to the sitemap is the quicker way.
> So, WDYT?
> Carsten

Carsten Ziegeler - Open Source Group, S&N AG

View raw message