I also suggest changing of package to org.apache.aries.blueprint.
*annotation*.config
2016-10-18 13:46 GMT+02:00 Dominik Przybysz :
> Hi,
> produces property-placeholder looks of course like this:
>
> http://aries.apache.org
> /blueprint/xmlns/blueprint-cm/v1.1.0" persistent-id="org.apache.aries.
Hi,
produces property-placeholder looks of course like this:
http://aries.apache.org
/blueprint/xmlns/blueprint-cm/v1.1.0" persistent-id="org.apache.aries.my"
placeholder-prefix="$[" placeholder-suffix="]" update-strategy="reload">
I also suggest changing org.apache.aries.blueprint.api.config
After discussing some more with Dominik I came up with this design:
https://github.com/apache/aries/blob/trunk/blueprint/blueprint-maven-plugin/src/test/java/org/apache/aries/blueprint/plugin/test/BeanWithConfig.java
The main annotations are @Config to configure the property-placeholder
Element
If you can share the config between components by using it in different
places then it can indeed work in the same way with blueprint.
I always though the idea in DS would be to only inject the config at one
place. (Lots to learn still :-)
Christian
On 12.10.2016 09:29, David Jencks wrote:
I’
I’m afraid I don’t understand what the problems you see are, perhaps because I
use blueprint so infrequently. Could you provide little code snippets to
illustrate?
Recall that in the DS approach many components in the same bundle can use the
same pid, and that a config annotation used by a DS
I like the approach in DS to supply the config in one event but I don´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 a
I don’t 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 annotati
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.
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}"
