You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Adrian Tarau <ad...@gmail.com> on 2010/12/27 22:44:22 UTC
VELOCITY-790
Hi all,
I reached a point in my journey where I need some feedback regarding some changes that I think it makes sense.
RuntimeServices offers some methods to inject overriding properties(ExtendedProperties) which are copied in the final configuration during initialisation.
I propose the following:
- setProperty, addProperty, cleaPropery should be removed, developers should change the configuration using the Configuration instance provided during initialisation.
- init() , init(Properies), init(String) should become init(Configuration) and it should not be in the RuntimeServices, only exposed in its implementation RuntimeInstance.
Any comments?
PS. Is the runtime reconfiguration of the engine desired(any need for this?) so I would implement a configuration listener? I would see some benefits from changing at runtime some of the parameters(adding new global macros files, parser settings, etc) but it is not that important.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: VELOCITY-790
Posted by Adrian Tarau <ad...@gmail.com>.
I would say just RuntimeInstance.init(Configuration). There is a
ConfigurationFactory which will provide configuration implementations
over maps & properties.
public final class ConfigurationFactory {
/**
* Creates a new configuration wrapping another configuration and
providing defaults from an additional
* configuration
*
* @param configuration configuration to wrap
* @param defaults configuration used to provide defaults
* @return wrapper configuration
*/
public static Configuration wrapConfiguration(Configuration
configuration, Configuration defaults) {
return new WrapperConfiguration(configuration, defaults);
}
/**
* Creates a new configuration instance based on a
<code>Properties</code> instance
*
* @param properties storage instance
* @return a Configuration instance
*/
public static Configuration newConfiguration(Properties properties) {
return new PropertiesConfiguration(properties);
}
/**
* Creates a new configuration instance based on a <code>Map</code>
object
*
* @param map storage instance
* @return a Configuration instance
*/
public static Configuration newConfiguration(Map<String, Object> map) {
return new MapConfiguration(map);
}
/**
* Creates a new empty configuration instance using a
<code>HashMap</code> as a storage
*
* @return a Configuration instance
*/
public static Configuration newConfiguration() {
return newConfiguration(new HashMap<String, Object>());
}
... implementations ...
}
On 12/27/2010 06:03 PM, Nathan Bubna wrote:
> Yeah, send all changes through the passed Configuration and definitely
> take init() out of RuntimeServices. I don't mind un-overloading
> init(...) so long as it is legitimate to call init(null) for manual
> init of the default configuration.
>
> On Mon, Dec 27, 2010 at 1:44 PM, Adrian Tarau<ad...@gmail.com> wrote:
>> Hi all,
>>
>> I reached a point in my journey where I need some feedback regarding some
>> changes that I think it makes sense.
>> RuntimeServices offers some methods to inject overriding
>> properties(ExtendedProperties) which are copied in the final configuration
>> during initialisation.
>>
>> I propose the following:
>> - setProperty, addProperty, cleaPropery should be removed, developers
>> should change the configuration using the Configuration instance provided
>> during initialisation.
>> - init() , init(Properies), init(String) should become init(Configuration)
>> and it should not be in the RuntimeServices, only exposed in its
>> implementation RuntimeInstance.
>>
>> Any comments?
>>
>> PS. Is the runtime reconfiguration of the engine desired(any need for this?)
>> so I would implement a configuration listener? I would see some benefits
>> from changing at runtime some of the parameters(adding new global macros
>> files, parser settings, etc) but it is not that important.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: dev-help@velocity.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: VELOCITY-790
Posted by Nathan Bubna <nb...@gmail.com>.
Yeah, send all changes through the passed Configuration and definitely
take init() out of RuntimeServices. I don't mind un-overloading
init(...) so long as it is legitimate to call init(null) for manual
init of the default configuration.
On Mon, Dec 27, 2010 at 1:44 PM, Adrian Tarau <ad...@gmail.com> wrote:
> Hi all,
>
> I reached a point in my journey where I need some feedback regarding some
> changes that I think it makes sense.
> RuntimeServices offers some methods to inject overriding
> properties(ExtendedProperties) which are copied in the final configuration
> during initialisation.
>
> I propose the following:
> - setProperty, addProperty, cleaPropery should be removed, developers
> should change the configuration using the Configuration instance provided
> during initialisation.
> - init() , init(Properies), init(String) should become init(Configuration)
> and it should not be in the RuntimeServices, only exposed in its
> implementation RuntimeInstance.
>
> Any comments?
>
> PS. Is the runtime reconfiguration of the engine desired(any need for this?)
> so I would implement a configuration listener? I would see some benefits
> from changing at runtime some of the parameters(adding new global macros
> files, parser settings, etc) but it is not that important.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org