On Tue, 29 Oct 2002 03:09, Igor Fedorenko wrote: > Not necessary. We can introduce additional configuration layer between > the container and the application which will define context > contributors, interceptors and other optional container services.
I like that - but that just becomes a generic hierarchial container. So each container has components and interceptors. Interceptors can use services of parent container while components can use services of their peers. I love the idea and think it is great. It is just a lot of work to get right ;) > > What I would really like to see is an experiment to see which way works > > better. So maybe it would be good to just see it in code and then we can > > decide whether it is the right way to do things? > > Take a look at JBoss. It has different container configuration for > different types of EJBs and target deployment environment (deploying CMP > beans into oracle is different from db2). Yep. But they have hierarchial containers. ie Interceptors don't depend on EJBs (equivelent to our blocks). > > The difficult part will be that being a ContextContributor essentially > > adds a new layer of dependencies. For example, assume a > > SecurityInterceptor (SI) requires a SecurityManager (SM). The SM can not > > depend on any block transitively (sp?) that uses the SI as part of it's > > interceptor chain. Actually coding this up is going to be fairly painful. > > > > I dunno. Maybe we just see how it looks in code? > > Sure. What exactly do you want to see, part that supports context > contributors in phoenix (this was surprisingly big change due to current > DefaultApplication/BlockEntry implementation), usage of context > contributors in some test app or both? Whatever you have got would be interesting to look at. -- Cheers, Peter Donald ----------------------------------------------- "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -Albert Einstein ----------------------------------------------- -- To unsubscribe, e-mail: <mailto:avalon-phoenix-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@;jakarta.apache.org>
