[ 
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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to