On Jan 14, 2008 6:28 PM, Padraic Hannon <[EMAIL PROTECTED]> wrote: > +1 for me as well. I know that jackrabbit tends to stick to apache > only libraries, however, if we could re-wire with Spring I think it > would be pretty slick and since most people already use it extensively > it wouldn't introduce a new technique for people to learn. I think it > would also put us a long way forward in making jackrabbit a bit more > modular.
-1 for introducing dependencies to any particular IoC container product. it should IMO always be possible to run jackrabbit stand-alone. however, i am not against making jackrabbit's configuration more IoC friendly (whatever that means) or some optional IoC container support. cheers stefan > > -paddy > > > On Jan 14, 2008, at 1:23 AM, David Rauschenbach wrote: > > > +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: dev@jackrabbit.apache.org > > 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 > > >
