There doesn't need to be any commitment to an IoC library. The main thing is to introduce the IoC concepts, which are realized by setter methods used to inject instances into other instances. If that's done, then Spring or any other framework could get the job done.
Personally, I like Spring a lot, but my employer is also looking into Nexus or whatever it is that drives Maven. Currently we use Hivemind, and we have Hivemind wrappers for Jackrabbit configuration. I can't overstate how much I hate Hivemind. It's rare that a piece of software is able to get in my way so completely. What I'd actually prefer is to see strong IoC support in all the components, so that I can use my own environment's IoC environment to string together the Jackrabbit components. In that case, the Jackrabbit examples can include Spring-based configuration, *and* pico container based configuration, etc. David -----Original Message----- From: Antonio López-Ceron Vivo [mailto:[EMAIL PROTECTED] Sent: Monday, January 14, 2008 10:46 AM To: dev@jackrabbit.apache.org Subject: Re: IoC configuration for Jackrabbit Spring is quite good general porpouse library, included some IoC concepts. But if you want just IoC, I think picocontainer is much more suitable container. Alexander Klimetschek wrote: > Do you intend to write the IoC container on your own? IMHO there is > good choice available out there: Spring (although it tends to put too > much of the config into XML, away from the code) or even OSGi, as > implemented by Felix and in use in Sling. I have used Spring a lot, I > think it is the best classical IoC container out there, but it still > is limited in its overall concept compared to OSGi. I am not sure how > to do repository.xml-style configurations with OSGi, but I suppose > there are ways. > > Apropos config: I often felt the need for a configuration of > Jackrabbit's components through code, especially when setting up test > cases that require an underlying Jackrabbit in a specific way. That > should IMHO be a design goal as well when changing the config > implementation. > > Just my 2 cents... > Alex > > > Am 14.01.2008 um 10:23 schrieb David Rauschenbach: > >> +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 > > -- > Alexander Klimetschek > [EMAIL PROTECTED] > > >
