polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Configuration structure
Date Sun, 04 Jun 2017 10:21:32 GMT
Well, I implemented the simple/hacky way now.

public interface MyConfig
{
    Property<String> osName();

    Property<String> home();

    Property<String> path();
}


will now read "os.name" from System Properties and $HOME and $PATH/%PATH%
of Environment variables.

Additionally, System properties takes precedence over environment
variables, so env variables can be overridden more easily.


Just pushed to 'develop' together with both yeoman stuff and more docs.

On Thu, Jun 1, 2017 at 11:02 AM, Niclas Hedhman <niclas@hedhman.org> wrote:

> 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 initial properties file?
>    3. Should it be only for first initialization, or should it use it even
> if an Entity is present?
>    4. Should there be some kind of "name space" in the System properties,
> or should the "name" be enough?
>
>
> I think it would be pretty cool if one could simply do;
>
> public interface MyConfiguration
> {
>     Property<String> osName();
>     Property<String> userDir();
> }
>
> and get those directly populated from System properties.
>
> Hmmm... Could that be done via Lifecycle?
>
> No, because the validation check kicks in before the Lifecycle methods are
> called.
>
> Maybe, just maybe, all this special handling in Configuration should
> actual be pushed to some type of Fragment that gets a go at it before the
> validation is done. Because if we could do that generically, and have a
> compatible implementation for current Configuration behavior, I think we
> are much much better off, and the semantics are effectively in the hands of
> users.
>
>
>
> I think we push it to 3.1 since there are too many questions to be hashed
> out and not enough time to try it out.
>
> On Tue, May 30, 2017 at 1:23 AM, Kent SĂžlvsten <kent.soelvsten@gmail.com>
> wrote:
>
>> 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 <niclas@hedhman.org>
>> wrote:
>>
>> > 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 <niclas@hedhman.org>
>> > wrote:
>> >
>> > > 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
>> > > first time, but if we are heading towards supporting external and
>> perhaps
>> > > more exotic configuration "supply-chains", then I think it would be
>> more
>> > > logical that the ConfigurationComposite simply reads what it wants and
>> > > ignores everything else.
>> > >
>> > > AND then would could have this super cool addition that if no files
>> are
>> > > found that works, fall back to System.getProperties() and
>> > System.getenv() as
>> > > the final backups.
>> > >
>> > > WDYT?
>> > >
>> > > Cheers
>> > > --
>> > > Niclas Hedhman, Software Developer
>> > > http://polygene.apache.org - New Energy for Java
>> > >
>> >
>> >
>> >
>> > --
>> > Niclas Hedhman, Software Developer
>> > http://polygene.apache.org - New Energy for Java
>> >
>>
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message