Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
From: David Jencks <david_jencks@yahoo.com.INVALID>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_7D43F814-2221-45A6-806A-83B7882B4003"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Subject: Re: [blueprint-maven-plugin] Ideas for config handling
Date: Tue, 11 Oct 2016 08:12:09 -0700
References: <b2096745-cb85-bbcd-e4e7-81a7d1fdc6a7@die-schneider.net>
 <CAA66TprQkXkh_YfKOMUSpS4BNrKeiAg=PBmTWm6x_1Lv6zWv0A@mail.gmail.com>
 <7eaabd35-9166-b675-2d41-cca0d6a0be0a@die-schneider.net>
To: dev@aries.apache.org
In-Reply-To: <7eaabd35-9166-b675-2d41-cca0d6a0be0a@die-schneider.net>
Message-Id: <2AA93D28-1A48-4B92-AB20-CB5179F32150@yahoo.com>
archived-at: Tue, 11 Oct 2016 15:12:25 -0000

--Apple-Mail=_7D43F814-2221-45A6-806A-83B7882B4003
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I don=E2=80=99t think i would consider ever recommending anyone use =
blueprint for anything, but if I were to design something like this I =
would take the opportunity to get one of the big advantages of DS also =
in blueprint, that all the configuration info is supplied in one event.  =
So using your annotation example (which would not need the =
@ObjectClassDefinition for this use)

@Inject @Named(<pid>)
private ServerConfig serverConfig;

When a configuration with the appropriate pid shows up, a ServerConfig =
implementation returning the values from the configuration is created =
and injected.  If the configuration is a factory configuration with the =
pid as the factory pid, then for each such configuration an instance is =
created.

This doesn=E2=80=99t have the flexibility of what DS does (multiple =
pids, no necessary direct connection between pid and configuration =
annotation) but something with those properties wouldn=E2=80=99t be hard =
to design.

Metatype is extremely useful and generating metatype from annotations is =
incredibly nice, but I would try to avoid requiring metatype for every =
configuration annotation.

david jencks

> On Oct 11, 2016, at 2:57 AM, Christian Schneider =
<chris@die-schneider.net> wrote:
>=20
> By default @Named("key") is used to inject a certain bean when type =
information alone is not unique. In blueprint-maven-plugin we map it to =
a bean id.
> So simply using the key for configs might overlap too easy. So I am =
not sure which exact syntax we should use but the simple name is not =
enough.
>=20
> Support of different placeholders is also something that would be =
great to support. It is rather rare but people use it.
> I think the must have is that we support placeholders from one config =
and the system properties or framework properties.
>=20
> Christian
>=20
> On 11.10.2016 11:22, Guillaume Nodet wrote:
>> I like the use of annotations for config.
>> I've implemented it for CDI and it's quite nice.
>> I'm not sure that reusing @ObjectClassDefinition is a good idea, =
afaik SCR
>> does not use it either.
>> I'd rather create a new blueprint annotation for such support.
>>=20
>> Also, I'm a bit skeptic about @Named("${key}") and =
@Named("$system{key}")
>> Why not using something simpler: @Named("key") and =
@Named("system:key") ?
>> Or is that to support multiple placeholders with different syntaxes =
(${xx},
>> $[yy]...) ?
>>=20
>>=20
>>=20
>> 2016-10-11 10:15 GMT+02:00 Christian Schneider =
<chris@die-schneider.net>:
>>=20
>>> Currently config is done in the blueprint-maven-plugin in this way:
>>>=20
>>> - Define a property-placeholder element in xml (using the cm =
namespace).
>>> This defines the reference to the pid and optionally the default =
values.
>>>=20
>>> - Use @Value("${key}") in the java code to inject a config value =
into a
>>> field.
>>>=20
>>>=20
>>>    Problems
>>>=20
>>>  * The approach above requires a mix of xml and annotations.
>>>  * @Value is a spring annotation. So the user code needs to refer to
>>>    the spring library (even if it is not needed at runtime)
>>>=20
>>>=20
>>>    Goals
>>>=20
>>>  * Pure annotation approach
>>>  * Should only need API dependencies in user code. Ideally these =
should
>>>    not bring unwanted additional annotations that we can not use.
>>>=20
>>>=20
>>>    Idea
>>>=20
>>> The OSGi meta type spec allows to define type safe config using
>>> annotations. We could use the same constructs to define blueprint =
configs.
>>>=20
>>> It looks like this:
>>>=20
>>> |@ObjectClassDefinition(pid=3D"my.config.id") @interface =
ServerConfig {
>>> String host() default "0.0.0.0"; int port() default 8080; boolean
>>> enableSSL() default false; }|
>>>=20
>>> This could be done in a new blueprint config namespace that enables =
the
>>> annotation processing. In this case the blueprint-maven-plugin just =
needs
>>> to add the namespace and enable element to the generated blueprint.
>>>=20
>>> Another approach is to parse the config in the =
blueprint-maven-plugin and
>>> create a property placeholder Element in our current style.
>>>=20
>>> If we have the above then we still need an annotation based way to =
inject
>>> the config. One possible solution would be to use @Named with a =
special
>>> syntax:
>>>=20
>>> @Inject @Named("${key}")
>>> String myAttribute;
>>>=20
>>> We could also cover system properties in this way:
>>>=20
>>> @Inject @Named("$system{key}")
>>>=20
>>> This approach has the advantage that it does not require any new
>>> annotation but it bends the purpose of the @Named annotation a bit.
>>>=20
>>> WDYT?
>>>=20
>>>=20
>>> Christian
>>>=20
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>=20
>>> Open Source Architect
>>> http://www.talend.com
>>>=20
>>>=20
>>=20
>=20
>=20
> --=20
> Christian Schneider
> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>=20
> Open Source Architect
> http://www.talend.com <http://www.talend.com/>

--Apple-Mail=_7D43F814-2221-45A6-806A-83B7882B4003--