+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.
-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: [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
