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 Fri, 20 Jan 2006 11:32:43 GMT
    [ http://issues.apache.org/jira/browse/JCR-306?page=comments#action_12363388 ] 

Jukka Zitting commented on JCR-306:

> The constructor for BeanConfig needs to be made public because all the Config
> elements rely on it for instantiation (right now the constructor is protected).

You are right, I'm sorry that I missed that.

The BeanConfig is not really meant to be a part of the public interface, it is currently used
in a bit cumbersome manner to construct the strongly typed Config subclasses by just passing
the parsed BeanConfig to the parent copy constructor from the Config subclass.

I changed the visibility of the BeanConfig constructors in revision 370793. I hope this covers
your immediate needs.

> 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