Carsten Ziegeler wrote:
Stephen McConnell wrote:
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?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.
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.
A.k.a identifiable lifestyle strategy.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.
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.
Yes, I think this is the case.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.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.
Carsten
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
