cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: Fortress Migration Strategy
Date Thu, 16 Oct 2003 08:34:53 GMT
Stephen McConnell wrote:
> >When you have a hierarchy of component managers (I still call them
> >component managers :) ), and you lookup a selector on the child CM
> >and then try to lookup a component using a hint that is not defined
> >in this selector but in a selector with the same role defined at
> >the parent CM, then the selector of the child CM can forward the
> >lookup to the parent one.
> >Actually this is used in Cocoon for all sitemap components resp.
> >for the selectors for these components. So a selector for a generator
> >in a sub sitemap gets via ParentAware a handler (locator) to get
> >the selector defined in the parent sitemap.
> >
> All of the above is implementation specficic description.  As far as the 
> client side of the equation is concerned - imagine you were 
> container-agnostic - is the client providing sufficient information for 
> a solution?  Yes - or no, can you provide a summary of the client 
> (consumer component) infromation that is available and how this 
> information is supplied to the contaier under the current implementation?

The client is not aware of this parent aware thing. It simply wants
to select a component using a selector and doesn't care if actually
this component is defined on this selector or on any parent selector.
This is like looking up a component from a normal CM.

> >Yes, basically. The typical use case is that you have *data*
> >the component works on that is tied to the current request
> >(or subrequest). So the usual way would be to use a poolable
> >component and tie the data to the request.
> >But this is bad for performance, because if e.g. this component
> >is looked up at three different places, you get three
> >instances and each component has to do a lookup in the
> >request attributes to get the data.
> >  
> >
> A.k.a identifiable lifestyle strategy.
> Can this be handled with a service .. e.g. getMySessionThing( 
> sessionID ) ?
Sure, but with performance costs. We have the o.a.c.components.persistence
package with such an implementation. But you have to get the data
each time you need it - and that's time consuming.

> Any reason wny this could not be moved to a service .. e.g.
>     StatsMagic magic = (StatsMagic) lookup( "magic" );
>     Specail special = magic.doSomethignSpecal( stats );
> I.e. the issue is a Coccon issue as opposed to an Avalon generic 
> container issue.
Might be; I don't that everything should be done at Avalon. If we
have to extend fortress again, I see no problem with that. We did
it for the ECM and we can do it for any other container as well.
Of course, it would be better for all if we don'T have to do it.

> >
> >>If each sub-request has its own "request context", then we can 
> convert the
> >>Global Request to a PerThread type of component.
> >>    
> >>
> >Yes, each sub request has an own "request context", so yes this 
> could work.
> >
> >But what happens if I process one request with multiple threads?
> >
> It breaks if you assume a per-thread lifestyle.
> What you describing is a per-key lifestyle. That needs a new lifestyle 
> handler in Avalon.

> What you describing is to me a "per-identity" lifestyle and that means 
> either (a) a specailized lifestyle handler in Fortress and Merlin or, a 
> gernic custom lifestyle object model.

> >Imagine a thread safe component that has a service method
> >that gets in a uri as a string and is used from various
> >places.
> >Now this thread safe component looks up a source resolver
> >on initialization, but it should resolve the uri provided
> >from a client of this component look up relative to the
> >sitemap the client was looked up.
> >
> To restate this is another terminology - the sitemap is establishing a 
> runtime context and this context needs to be exposed to other components 
> that we can consider as children (or scoped) components relative to the 
> sitemap.  I.e. we have a container that has aquired a sitemap, the 
> container interprets the sitemap and sets up a number of subsidiary 
> components that will enable execution of the sitemap fragment, the 
> components will require some context data that is based on(opr derived 
> from) the site map.  During runtime invocation the components 
> implementations will be adaptive to the supplied context arguments.
Yes, I think this is the case.

View raw message