jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Jackrabbit configurability
Date Tue, 11 Oct 2005 12:17:17 GMT
On 10/11/05, Jukka Zitting <jukka@zitting.name> wrote:
> 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?

personally i am concerned that such a general component framework would just
add unnecessary complexity/dependencies without adding real benefits.
for version 1.0 i suggest we keep the current configuration mechanism
as there's
IMO nothing wrong with it. i wouldn't mind considering such a change
for version
1.1 or 2.0 once we've thoroughly analyzed the total costs/benefits and reached a
positive conclusion.


> BR,
> Jukka Zitting

View raw message