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.
+1. That was one of the concerns I expressed when seeing more and more features going into the core container. We should stick it to the well-known old ECM behaviour (plus a few additional bonuses like proxied poolable), and not try to extend it up to being a full-blown POJO container.
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.
+1 as well. Such listeners could be declared a bit like in CForms, and I currently see 4 types of listeners :
- on-enter (entering a sitemap)
- on-pipeline-built (a pipeline has been built, but not yet executed)
- on-execute-pipeline (the previously built pipeline is executed)
- on-leave (going out -- needs to have the information of success, no match or exception)
on-pipeline-built and on-execute-pipeline are IMO needed to handle the strict separation of these phases in the case of internal ("cocoon:") processing.
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.
Back in fall 2004 I started prototyping an implementation of an Avalon component with Spring. Although technically feasible, this proved to require some work to be able to merge both configuration styles in a single file or convert Avalon-style xconf into Spring-style bean definitions. A lot of DCC-specific code to write and maintain.
Now we actually don't have to mix them, but simply use the hierarchical nesting capabilities of both our containers and most (if not all) DCCs.
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!
Yes. Actually most of what is needed for this is a set of bidirectional adapters between ServiceManager and the equivalent interfaces in DCCs. That would allow for a DCC to be a parent of our core service manager and reciprocally.
A component will then be managed by the appropriate CC (component container) type, and be available in that CC and all its children, whatever their kind. Proxied poolables is probably key to allow this as AFIACS not all DCCs have explicit release().
We could extend this and add some additional glue code that makes core
Cocoon features (like the Context, settings etc.) available to the DCC.
Yes. Since DCCs don't have a complex lifecycle as Avalon, the Context should be available as a component, and not only through a separate lifecycle interfaces.
Another very Cocoon-specific component is the SourceResolver. Since now manage our classloaders, we could benefit from the 3rd constructor parameter of URLClassLoader which is a URLStreamHandlerFactory.
That would give access to the rich set of Cocoon-defined protocols using java.net.URL. Can you imagine writing "new URL("cocoon://blah").openStream()"? That would be cool :-)
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.
+1
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.
Yup. Embrace and extend. Cocoon has done this for most of ASL-compatible XML-capable components, let's do it now with POJO containers :-)
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.
Yes. Let's start it there, using includes if necessary to handle external config files. Refactoring of config file handling can happen later.
So, WDYT?
Enthusiastic +1!
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
