jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-306) repositoryConfig should use setter for its internal components
Date Thu, 19 Jan 2006 11:12:42 GMT
    [ http://issues.apache.org/jira/browse/JCR-306?page=comments#action_12363235 ] 

Stefan Guggisberg commented on JCR-306:

note that allowing an application to dynamically modify the configuration 
*after* the repository has been initialized may lead to unexpected results.

jackrabbit's code expects the configuration to be immutable. public access 
modifyers and setters have been intentionally omitted for this reason.

if those are to be made public the documentation has to clearly and explicitly 
mention the danger of dynamically changing the configuration.

personally i'd prefer a tool where a config xml file/dom tree could be easily built 
programmatically rather than messing around with the live config.

> repositoryConfig should use setter for its internal components
> --------------------------------------------------------------
>          Key: JCR-306
>          URL: http://issues.apache.org/jira/browse/JCR-306
>      Project: Jackrabbit
>         Type: Improvement
>   Components: config
>     Versions: 0.9
>     Reporter: Costin Leau
>  Attachments: RepositoryConfig.patch
> From the mailing list (not archived at the moment):
> --- Jukka's reply ---
> I refactored the config classes last year but didn't change the way
> the config instances are being used by Jackrabbit. In general I think
> that a IoC approach (use setters to configure the Jackrabbit
> components) would be better than passing config objects around and
> letting the components to instantiate any subcomponents based on the
> configuration. This is why I didn't really want to make the config
> constructors public, otherwise we'd easily up with backwards
> compatibility issues if we were to change the way configuration is
> handled.
> ---

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message