For what its worth, I think we are all actually talking about the same thing here, but we have divergent opinions on the implementation. These are good discussions and hopefully they will bring clarity and consensus.
Just a couple of comments inline below... On 7/18/07, David Jencks <[EMAIL PROTECTED]> wrote: <SNIP> So I think that the idea of making the components container agnostic is a
great idea and I think the best way to do that is to start by removing the configuration objects and dealing directly with the functional components, as Chris and I have been suggesting.I think you are also seriously underestimating the difficulty of writing a usable container framework. AFAIK Spring doesn't do too much except act as a wiring framework, but at least it works and is well understood. IIUC it does not really do dependency management which I think is required for changing configuration without restarting the entire server on any change. When I looked at OSGI it had a nice classloader and a big spec, but I couldn't find a wiring framework or component model or component dependency management. (I'm sure I missed a lot of OSGI). Geronimo makes you describe the component metadata in a rather inconvenient java form although it has a wiring framework and dependency management. I think a reasonable path to follow would be to: -- stop abusing spring, i.e. remove the configuration objects and make the functional objects container agnostic. -- consider xbean-spring to make type-checked configuration files
Another step here would be to write some Spring extensions (extend AbstractApplicationContext, et al) to load our bean definitions from an LDAP schema. I have written code that extends Spring to read bean definitions from JDBC and other sources that aren't built in to Spring and it works just fine. This way we can store custom config in a schema, but still use all of the DI framework, etc. -- do some experiments to see about ldap <> component mappings. Maybe Ole's
system will be lightweight enough to be used for server startup. Maybe you can write something else that works and is easy to extend to new components. -- if those experiments succeed, try storing the configuration in the dit.
<SNIP> Someone suggested a while back that we avoid the "jdo for ldap" problem by
> > > just storing server.xml in ldap as text. IIUC this could be done in > > > a couple of days. Exactly how much really useful functionality would this > > > lose compared to the fine grained approach? > > > > >
Maybe this could be an incremental part of this overall task. I think it will also help us refine the approach as we go along without doing too much work.
