Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
MIME-Version: 1.0
Sender: cschneider111@gmail.com
In-Reply-To: <2AA93D28-1A48-4B92-AB20-CB5179F32150@yahoo.com>
References: <b2096745-cb85-bbcd-e4e7-81a7d1fdc6a7@die-schneider.net>
 <CAA66TprQkXkh_YfKOMUSpS4BNrKeiAg=PBmTWm6x_1Lv6zWv0A@mail.gmail.com>
 <7eaabd35-9166-b675-2d41-cca0d6a0be0a@die-schneider.net> <2AA93D28-1A48-4B92-AB20-CB5179F32150@yahoo.com>
From: Christian Schneider <chris@die-schneider.net>
Date: Wed, 12 Oct 2016 07:50:24 +0200
Message-ID: <CAH6_LNk6z3MqVfOLrgFpd1HizBa8P6v_S=LFrdLhQzg4nEUQhw@mail.gmail.com>
Subject: Re: [blueprint-maven-plugin] Ideas for config handling
To: dev@aries.apache.org
Content-Type: multipart/alternative; boundary=001a113fc1acc803dd053ea491fb
archived-at: Wed, 12 Oct 2016 05:50:34 -0000

--001a113fc1acc803dd053ea491fb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I like the approach in DS to supply the config in one event but I don=C2=B4=
t
think it matches how dependency injection in blueprint works.

In blueprint that config is often applied in different beans. Each bean is
injected with config and its dependencies. Only after this step the
init-method is used and the bean is injected into other beans. If I would
get the config in a single event then it would be too late to inject it
into other beans.

So the only way I could imagine this to work is to inject the full config
into each bean that needs it. This could be done a parameter of the init
method (which is then similar to DS).
The problem is that then several beans are tied together by the config even
if they just need one attribute of it. Another problem is that by applying
the config in each bean separately (and I think this is the only safe
approach in blueprint) we loose the advantage of the single event.

So while I am sure we can technically do it like in DS I think it would
work less well from a design point of view.

Christian

2016-10-11 17:12 GMT+02:00 David Jencks <david_jencks@yahoo.com.invalid>:

> I don=E2=80=99t think i would consider ever recommending anyone use bluep=
rint 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, tha=
t
> 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 a=
s
> 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:
> >
> > 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.
> >
> > 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.
> >
> > Christian
> >
> > 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.
> >>
> >> 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]...) ?
> >>
> >>
> >>
> >> 2016-10-11 10:15 GMT+02:00 Christian Schneider <chris@die-schneider.ne=
t
> >:
> >>
> >>> Currently config is done in the blueprint-maven-plugin in this way:
> >>>
> >>> - Define a property-placeholder element in xml (using the cm
> namespace).
> >>> This defines the reference to the pid and optionally the default
> values.
> >>>
> >>> - Use @Value("${key}") in the java code to inject a config value into=
 a
> >>> field.
> >>>
> >>>
> >>>    Problems
> >>>
> >>>  * 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)
> >>>
> >>>
> >>>    Goals
> >>>
> >>>  * Pure annotation approach
> >>>  * Should only need API dependencies in user code. Ideally these shou=
ld
> >>>    not bring unwanted additional annotations that we can not use.
> >>>
> >>>
> >>>    Idea
> >>>
> >>> The OSGi meta type spec allows to define type safe config using
> >>> annotations. We could use the same constructs to define blueprint
> configs.
> >>>
> >>> It looks like this:
> >>>
> >>> |@ObjectClassDefinition(pid=3D"my.config.id") @interface ServerConfig=
 {
> >>> String host() default "0.0.0.0"; int port() default 8080; boolean
> >>> enableSSL() default false; }|
> >>>
> >>> This could be done in a new blueprint config namespace that enables t=
he
> >>> annotation processing. In this case the blueprint-maven-plugin just
> needs
> >>> to add the namespace and enable element to the generated blueprint.
> >>>
> >>> Another approach is to parse the config in the blueprint-maven-plugin
> and
> >>> create a property placeholder Element in our current style.
> >>>
> >>> 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 speci=
al
> >>> syntax:
> >>>
> >>> @Inject @Named("${key}")
> >>> String myAttribute;
> >>>
> >>> We could also cover system properties in this way:
> >>>
> >>> @Inject @Named("$system{key}")
> >>>
> >>> This approach has the advantage that it does not require any new
> >>> annotation but it bends the purpose of the @Named annotation a bit.
> >>>
> >>> WDYT?
> >>>
> >>>
> >>> Christian
> >>>
> >>> --
> >>> Christian Schneider
> >>> http://www.liquid-reality.de
> >>>
> >>> Open Source Architect
> >>> http://www.talend.com
> >>>
> >>>
> >>
> >
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de <http://www.liquid-reality.de/>
> >
> > Open Source Architect
> > http://www.talend.com <http://www.talend.com/>
>


--=20
--=20
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3D3aa4083e0c744ae1ba52bd062c5a7e46=
&URL=3Dhttp%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3D3aa4083e0c744ae1ba52bd062c5a7e46=
&URL=3Dhttp%3a%2f%2fwww.talend.com>

--001a113fc1acc803dd053ea491fb--