We added in 2.1 several lifecycle extensions to the ones already provided by Avalon: The request lifecycle, the global request lifecycle and parent aware.
While it seems to be possible to support the two request lifecycles in 2.2 (with fortress), I currently see no real way to support parent aware (but perhaps there is a way). However, I think we should avoid adding our own lifecycle interfaces whereever possible. So, let's think about them: ParentAware ----------- Has been introduced to have a cleaner implementation for the selectors used in the sitemaps. I think/hope this is not an issue with fortress anymore. So, unless ParentAware is needed somewhere else, we could remove it. The implementation is always tied to a specific container which makes moving to another one more difficult. RequestLifecycle ---------------- I'm really thinking more and more that we simply should drop RequestLifecycle and GlobalRequestLifecycle. Why? In most cases they are not used for the lifecycle of the component but for the lifecycle of the data the component acts on. This was basically the initial use case. In fact, the implementation is a little bit tricky or someone might call it even hacky. The implementation is tied to a specific container. You can achieve the same thing now by using the o.a.c.components.persistence.RequestDataStore which is imho a cleaner solution as it doesn't require to change the container. So with this solution we are container independent. Currently, you look up during the request the RequestLifecycleComponent whereever you need it and get the data from this component. So, this is one lookup per data access. With the RequestDataStore it's basically the same. You lookup the store once (it's thread safe) and look up during the request the data object from the store. So again, this is one lookup per data access. So, I'm in favour of deprecating this in 2.1 now and removing it in 2.2. WDYT? Carsten Carsten Ziegeler Open Source Group, S&N AG http://www.osoco.net/weblogs/rael/
