Hi, 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? BR, Jukka Zitting
