On 10/11/05, Jukka Zitting <[EMAIL PROTECTED]> 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 >
