cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Fortress Migration Strategy
Date Thu, 16 Oct 2003 17:57:35 GMT


Carsten Ziegeler wrote:

>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.doSomethingSpecal( 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.
>

Extending is IMO a really *bad* thing to do - but I also agree that
Avalon should not be doing everything.  The real problem is related
to the extension approach. If your adding semantics to a
service/component manager (as is the case with ECM) then you should
be doing this under a different interface. If you want to continue
with Avalon semantics then its a case of addressing the question of
sufficiency of the Avalon component/container contract.  For example,
Leo mentioned earlier the point concerning interceptors.  Interceptors
enable you to change the behaviour (i.e. add domain specific semantics).

Take as an example the selector model.  Instead of doing things like
appending "Selector" to an interface name (thereby adding semantics
above and beyond the strict framework spec) - you could be declaring
a component dependency on a typed selector e.g.:

  @avalon.dependency type="example.FilterSelector" key="filters"

Under strict avalon this would enable to lookup the filter selector
using the lookup argument "filter" - but you would still need to
invoke the query based lookup.  An interceptor would enable you to
package that selection logic as a separate component that would
dynamically applied at the moment of lookup invocation.  The
interceptor could apply the selector query, get the result, and
replace the return object with the selected object.

This would require the definition of an interceptor API and
additions to the component type meta-info, i.e. some time needed
to get that in place - and the upside would be that none of your
components would see a container specific API - *AND* none of
your components would be making domain specific semantic
assumptions. And that means that Cocoon as a project would
benefits on a daily basis from Avalon development.

Fortress is a step in the process of getting Cocoon from ECM to
strict framework compliance. There are some prereqs that Fortress
has to deal with *before* the 2.2 updating take place.  This
concerns updating Fortress to use the avalon-meta API and which
includes moving Fortress from its current tag set to the full
@avalon tag set.  Once that it done - then Cocoon can:

1. migrate from ComponentManager to ServiceManager
2. migrate from marker interface to meta-tags

Achieving this means that we can look at specific semantic
deviations and figure out haw these can be handled in an Avalon
container in a standard way (e.g. interceptors or whatever).



Stephen.


>>>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.
> 
>Carsten
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




Mime
View raw message