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]
