Mailing-List: contact dev-help@polygene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@polygene.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: <CAHpT5g4oYDrDygLyp6nQiaEvar6ySw+KAqR4ZG_5fuMoHOX35g@mail.gmail.com>
References: <CADmm+KedxS0XeQi=0Yajrmizy8oEK6e7ahZGgvfPKKT+FPLA=g@mail.gmail.com>
 <CADmm+KcoujdAZzyS43oG2bWT6GJG04tK1R9uY3UK5PuvJ_AsYg@mail.gmail.com> <CAHpT5g4oYDrDygLyp6nQiaEvar6ySw+KAqR4ZG_5fuMoHOX35g@mail.gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Thu, 1 Jun 2017 11:02:59 +0800
Message-ID: <CADmm+Kd1ULAAb6YA1_GKTYM+NxJFOxO2kwLUfJSUEgtdSDBtpQ@mail.gmail.com>
Subject: Re: Configuration structure
To: dev@polygene.apache.org
Content-Type: multipart/alternative; boundary="94eb2c184bfa754e770550dd47be"
archived-at: Thu, 01 Jun 2017 03:03:26 -0000

--94eb2c184bfa754e770550dd47be
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=C3=B8lvsten <kent.soelvsten@gmail.c=
om>
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" reaso=
ns
> 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 ther=
e
> > are
> > > declared and matching Proprety<> methods, then there is an Exception.
> > >
> > > This might have been rational back in the days when this was discusse=
d
> > > 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 an=
d
> > > ignores everything else.
> > >
> > > AND then would could have this super cool addition that if no files a=
re
> > > 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
> >
>


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

--94eb2c184bfa754e770550dd47be--