Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
Message-ID: <55A399CF.7050205@nosphere.org>
Date: Mon, 13 Jul 2015 12:58:23 +0200
From: Paul Merlin <paul@nosphere.org>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@zest.apache.org
Subject: Re: Configuration initialization
References: 
 <CADmm+Kcw0UPdxHoquJYfrN2emK_aXzC3e_vuuUqhZbWE=3tC9g@mail.gmail.com>
In-Reply-To: 
 <CADmm+Kcw0UPdxHoquJYfrN2emK_aXzC3e_vuuUqhZbWE=3tC9g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Niclas Hedhman a =C3=A9crit :
> We all should know that Configuration Composite is an Entity, read from=
 an
> EntityStore and runtime modifiable just like any Entity.
>
> We also know that if it is not found in the Entity Store, the value is =
read
> from a properties file, named after the identity of the Service Composi=
te
> the configuration belongs to.
>
> I am now adding that in addition to Properties files, the file can be r=
ead
> via ValueSerialization instead. I am also adding that YAML is a format =
we
> intend to support (I really like that format for Config data).
>
> But currently there is no YAML ValueSerialization extension available. =
If
> someone feels itchy to help out; Creating a ValueSerialization extensio=
n
> for YAML, with the help of SnakeYaml or YamlBeans.
>
> Since the code is virtually the same inside the Configuration, I will r=
ely
> on this will get done sooner or later, and my tests are only covering J=
SON
> and XML for now.

I took a couple hours to start a YAML serialization extension. Both
SnakeYaml and YamlBeans gave me headhaches when it came to switching
from pull-parsing to tree-parsing for deserialization. Looks like theses
libraries are not built for advanced usecases. I'll need some more time
to come up with something usable.


Niclas Hedhman a =C3=A9crit :
> And to make this more "integrated", I am introducing
>
> ModuleAssembly.configurations()
>
> since otherwise people will be confused that both a entity and a value
> needs to be declared.
>
> (Actually, this speaks even more in favor of proposal to
> "Entity=3DIdentity+Value")
>
> The assembly will take care of duplicating the declared types as both
> entities and values, so there won't be a ConfigurationInstance type, at
> least not in 2.1.
>
> Any thoughts?

I'm all in favor for going towards "Entity=3DIdentity+Value". In the end,
this will allow us to drop a bunch of code as EntityState serialization
in EntityStores is pretty different than ValueSerialization (was already
before I rewrote ValueSerialization for 2.0). And I don't see the need
for theses differences.

/Paul