cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] Separation of Blocks and Avalon
Date Fri, 10 Oct 2003 15:19:48 GMT
Giacomo Pati wrote:
>
> > We extend the ECM with our CocoonComponentManager, you can have a look
> > at that class. All the features (hacks?) in there have to be somehow
> > available using fortress, merlin or whatever.
> > We have another lifecycle type, the request lifecycle component. This is
> > an extension to poolable and means that per request only one instance
> > of this component is used. So if two other components lookup this
> > request lifecycle component, they get the same instance.
> > The implementation of this extension is a little bit difficult as we
> > have sub requests that run in the same thread but have a different
> > set of request lifecycle components.
> > In addition it's possible to process on request multi threaded which
> > makes this even more difficult.
>
> IIRC Fortress can handle this with a special Handler we have to supply
> (instead of subclassing the hole Container class). Remeber that in
> Fortress Object handling is separated into meta data instead of
> additional marker interfaces. There is no Poolable, ThreadSafe, etc. any
> more but ThreadSafeComponentHandler, PoolableComponentHandler instead.
>
Yes, I know - and I saw the handlers of fortress and it should work.

> > There are some other important extensions like the environment handling
> > for the source resolver and the sitemap configurable components. They
> > use more or less the same technique used for the request lifecycle
> > components.
>
> I'm sure there is a way for this also and with the help of a Handler it
> can be made with IOC in mind.

I'm not sure for the source resolver part. The other things should work,
yes.

>
> Yes, but the world is still spinning and there are alot of other
> Component out there that don't follow the ECM style because it's
> deprecaded for long time now and every time we want to use such a
> component we have to extend the working interface to make it a
> 'Component' for ECM and extend the implementation to have our interface
> implemented (do you remember the Cornerstone Scheduler?).  That's ugly!
>
Definitly. Ok, that's a point.

> As a side note: I got the impression (and that supprises me alot) there
> is too little knowledge around here what Avalon is doing and where it is
> moving in the so central Component Container discipline. This IMHO led
> to this 'we think Avalon cannot supply what we want' situation and so we
> are ignoring the helping hand Avalon people put forth several times now.
>
At least for me it's not the 'we think Avalon cannot supply what we want'
that I fear of. It's more a "can the Avalon community support the version
for us and for how long".

Carsten


Mime
View raw message