cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject [RT] Another step to blocks: Application container support
Date Fri, 11 Mar 2005 18:45:56 GMT
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.


Carsten Ziegeler - Open Source Group, S&N AG

View raw message