Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <423228FC.6070501@apache.org>
Date: Sat, 12 Mar 2005 00:25:48 +0100
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Another step to blocks: Application container support
References: <4231E764.9040300@apache.org>
In-Reply-To: <4231E764.9040300@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 }