Should Contexts themselves be configured by DI?
Was writing a util and, of course, now everything will be a pojo (which lead me to some OOP ponderings...) and then had another thought.
When one creates contexts one configures them in external places, such as web xml or java code. Specifically the hierarchy. Thus, I'm pondering, shouldn't there we a way to declaritively define this hierarchy within the context definitions?
For example, the beans element could have a 'contexts' attribute that contains a list of contexts that partake in a relationship. Better yet, beans could have a child element, 'contexts', that can contain a richer element content.
- One value add is that it constrains the look-up of beans. Given context xml files, unless one resorts to code inspections of other configuration data (web.xml, xxx-servlet.xml, ..) one does not know what bean is resolved. Or one can use the IDE tool. And if a Spring module is componentized how do we know bean names really are unique or what the deployer or user configures the application? This may be out of scope of course.
- To support standalone 'components' (there is another thread in this forum about this).
- Another use, is to allow DI of contexts. Thus, no need to use xml includes for example.
- Still another is easier tools to support Spring use (I bet the Spring Eclipse plug-in would be easier to write).
I don't like the use of 'parent' for this since this precludes the use of siblings or other richer relations.
<beans blah blah......>
<context refID="root" access="public" ..... etc.>
I hope after all this typing someone doesn't tell me this is already in Spring, just do a one line thing somewhere. :)
--- Josef Betancourt
Re: Should Contexts themselves be configured by DI?
This is already in Spring, :-), although not necessarilly exactly how you describe it. But you can certainly define a hierarchy of contexts, using the keyed singleton variants of BeanFactoryLocator. Look here.
Originally Posted by jbetancourt