From: Adrian B. <adr...@jb...> - 2005-11-21 23:08:35
|
On Mon, 2005-11-21 at 17:52, Scott M Stark wrote: > Ok, let's keep drilling. First, I view the configuration you show as too > much of an inside out view of the container. Maybe its just an > irrelevant composition choice in terms of the real point of this > discussion, but I don't want the actual Container1ENC bean in either the > kernel registry or metadata registry. I only want the ReadOnlyContext > facade available for injection: > > <!-- Who uses it --> > <bean name="Container1"> > <!-- What it is --> > <property name="Container1ENC"> > <bean> > <!-- Definition of ENC --> > </bean> > </property> > > <!-- ENC annotation --> > <!-- Link to context in the repository (used by many decorators)--> > </bean> > > How would I express "Where the ReadOnlyContext view of Container1ENC go > in the repository" concern? I don't support anonymous beans yet and/or beans as values. :-( This just means all your beans are top level with an explicit name, there is no loss of functionality. In anycase, you are correct. I had anticipated your question with this usecase. For ejbs there is one per component. For wars there is one per application (shared across servlets). This is why you need a separate notion of ENC. I'd view anything that is truly a cross cutting concern to be a separate concept. Why restrict ourselves to the "compositional" choices made by the J2EE spec? e.g. Why not allow an ENC shared across all ejbs in a deployment? Or maybe you construct the ENC and ejb containers "programatically" with whatever topology you want. -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |