Ok... I'll strip it out.
On Mon, Jun 5, 2017 at 3:41 PM, Paul Merlin wrote:
> Le 2017-06-04 16:09, Niclas Hedhman a écrit :
>
>> By that rationale, we should remove properties/xml/json/yaml files as
>> well,
>> right?
>>
>
> :)
>
> Yeah, maybe, maybe not.
>
> What I dislike in the added logic is
Le 2017-06-04 16:09, Niclas Hedhman a écrit :
By that rationale, we should remove properties/xml/json/yaml files as
well,
right?
:)
Yeah, maybe, maybe not.
What I dislike in the added logic is that it exposes the application to
the environment through a naming convention that does not invol
By that rationale, we should remove properties/xml/json/yaml files as well,
right?
On Sun, Jun 4, 2017 at 8:37 PM, Paul Merlin wrote:
> Le 2017-06-04 13:23, Niclas Hedhman a écrit :
>
>> initialValueProvider should be marked "incomplete" or something.
>>
>
> I'd rather simply remove it from the
Le 2017-06-04 13:23, Niclas Hedhman a écrit :
initialValueProvider should be marked "incomplete" or something.
I'd rather simply remove it from the api for now.
I'll do that if no one yell :)
For the rest, not so sure I like it. I think I would prefer something
more
composite-like, but not
initialValueProvider should be marked "incomplete" or something.
For the rest, not so sure I like it. I think I would prefer something more
composite-like, but not sure yet.
On Sun, Jun 4, 2017 at 7:01 PM, Paul Merlin wrote:
> Maybe a silly idea, don't know, totally different, but ...
>
>
> int
Maybe a silly idea, don't know, totally different, but ...
interface MyConfig {
@UseDefaults( value = "user.home", source =
DefaultsSource.SYSTEM_PROPERTIES )
Property homeDirectoryPath();
@UseDefaults( value = "SOME_PORT", source = DefaultsSource.ENVIRONMENT
)
Property thePortWeWa
Yes, to everything;
It is fallback if properties file, json, xml or yaml files can't be found,
then it will do this, and yes, if the config es is persisting it will not
be using them next start.
And yes, both System properties and Environment variables are "copies" of
the System.getProperties() a
Le 2017-06-04 12:21, Niclas Hedhman a écrit :
Well, I implemented the simple/hacky way now.
public interface MyConfig
{
Property osName();
Property home();
Property path();
}
will now read "os.name" from System Properties and $HOME and
$PATH/%PATH%
of Environment variables.
Ad
Well, I implemented the simple/hacky way now.
public interface MyConfig
{
Property osName();
Property home();
Property path();
}
will now read "os.name" from System Properties and $HOME and $PATH/%PATH%
of Environment variables.
Additionally, System properties takes precedence ove
By allowing the fallback to system properties and/or environment variables
for configuration, it would be a lot easier to provide configuration from
commandline. But the devil is in the details.
1. Should it be fallback for a single unset property?
2. Should it be only for complete missing i
I think it is a very good idea.
As long as we retain an opt-out possibility to avoid accessing the
system-properties (reasons to avoid them could either be "pureness" reasons
or the presence of a securitymanager).
On Mon, May 29, 2017 at 9:33 AM, Niclas Hedhman wrote:
> The least intrusive impl
The least intrusive implementation of this is to take out the exception
thrown on org/apache/polygene/api/composite/PropertyMapper.java:117. Then
add the backup for the two maps mentioned above, with some
strategy/priority.
Niclas
On Mon, May 29, 2017 at 1:47 PM, Niclas Hedhman wrote:
> Hi,
>
>
Hi,
at the moment, the content of the properties file drives what is expected
in the ConfigurationComposite. If there are more properties than there are
declared and matching Proprety<> methods, then there is an Exception.
This might have been rational back in the days when this was discussed
fir
13 matches
Mail list logo
