jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <ju...@zitting.name>
Subject Jackrabbit configurability
Date Tue, 11 Oct 2005 12:01:27 GMT

JCR-220 got me thinking about the configurability of Jackrabbit. The current
configuration mechanism allows a deployer to select the main component classes
and to specify string properties for the configured components. In essence the
current configuration mechanism is a custom dependency injection system with a
predefined component structure.

I'm wondering whether it would make sense to adopt a more general component
framework (Spring, HiveMind, etc.) for Jackrabbit. Such a change would
eliminate much (or all) of org.apache.jackrabbit.core.config and require at
least some modifications to the current Jackrabbit components.

There are some use cases for a more flexible configuration mechanism (e.g.
JCR-220), but I'm not sure about the total benefits vs. costs of such a change.
What do you think, should such a change be made now, later (version 1.1 or 2.0),
or never?


Jukka Zitting

View raw message