Jackrabbit configurability

[Jukka Zitting <ju...@zitting.name>]

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

Re: Jackrabbit configurability

[Stefan Guggisberg <st...@gmail.com>]

On 10/11/05, Jukka Zitting <ju...@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.

cheers
stefan


>
> BR,
>
> Jukka Zitting
>