+1 for more IoC. We have a lot of code here that is factory wrappers for the proprietary Jackrabbit configuration, plus mock FileSystem implementations where a node type manager is used in a stand-alone fashion. It's all very pre-IoC looking.
David -----Original Message----- From: Jukka Zitting [mailto:[EMAIL PROTECTED] Sent: Sunday, January 13, 2008 7:57 PM To: [email protected] Subject: IoC configuration for Jackrabbit Hi, The current repository.xml configuration file and the related o.a.j.core.config code is quite monolithic and essentially fixes the structure of Jackrabbit internals. For example, almost all notable new features require that you either modify the configuration handling code (clustering, data store, ism locking) or just work around it (indexing). The configuration model also makes us duplicate lots of code. For example, instead of using a single database configuration and an associated class/object, we now need to duplicate database connection code in persistence managers, file systems, cluster journals, and data stores. It's a mess. To fix this, I'd like to make Jackrabbit configuration more IoC-like, eventually making it possible to use an existing IoC library/container to configure Jackrabbit. To make this happen, I'd start by dropping the type-specific SomeConfig classes from o.a.j.core.config and replacing the init(...) methods with setters and more explicit lifecycle management methods. WDYT? This'll probably require some relatively heavy-handed refactoring, changes to the repository.xml structure, and probably some backwards-compatibility code to handle Jackrabbit 1.4 and earlier configuration files, so I won't go forward unless we have a reasonable consensus that the benefits are worth the effort. BR, Jukka Zitting
