jackrabbit-dev mailing list archives

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

Jukka Zitting commented on JCR-306:

I agree that keeping the config objects immutable would be good. A better solution than the
proposed patch is just to make the config constructors public. That way we'd get some of the
dynamic configurability that Costin needs while keeping the config objects immutable. (Of
course the classes are not final, so they are not absolutely immutable. Any objections to
making them final?)

I think that a ComponentBuilder (essentially an IoC tool) would be a better approach than
a ConfigBuilder, because it would give much more flexibility. For example a database persistence
manager could then have a DataSource as a configuration option instead of the database connection
settings. But that's a different discussion.

> 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
>     Reporter: Costin Leau
>     Assignee: Jukka Zitting
>      Fix For: 0.9
>  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