Hi David,
a question regarding a new Configurator concept: are there any plans to add
runtime Configuration validation? Smth like configuration validating
service.
It could be used with DS config classes like:
@Config{
@NumberRangeValidation(
@Range("(1023, 65535]")
}
int port() default 1111;
....
}
@Reference
ConfigValidationService validator;
@Activate(Config config) {
validator.validate(config); // in case of any issues with config values
- throws IllegalArgumentException
.....
}
--
Best regards,
Dmytro Pishchukhin
On Fri, Jul 8, 2016 at 10:50 AM, David Bosschaert <
[email protected]> wrote:
> Hi Brad,
>
> In OSGi currently the concept of a Configurator is being developed. It's
> orthogonal to Blueprint or DS and can be used with either of them. It might
> touch on the ideas that you mentioned here. You can find the current
> configurator design in RFC 218:
> https://github.com/osgi/design/tree/master/rfcs/rfc0218
> Maybe this might be something that could be of use.
>
> Additionally, the OSGi ConfigAdmin spec permits the same configuration to
> be consumed by multiple bundles. That might also be of use to you if you
> want to share configurations. The bundle location for the configuration
> should be set to '?' in that case (see Config Admin spec 104.4.1).
>
> Cheers,
>
> David
>
> PS feedback on the RFC is appreciated, see here:
> https://github.com/osgi/design
>
> On 7 July 2016 at 18:53, Brad Johnson <[email protected]>
> wrote:
>
>> As I work in more environments now that want to use microservices the
>> limitations of the blueprint properties mechanics become a bit hairier. I
>> commonly find that I have bundles that have common properties shared across
>> them and I can't find a good solution other than creating my own OSGi
>> service for serving them up for such crosscutting concerns.
>>
>> I'm not an expert on the specification and implementations of compendium
>> or blueprint libraries so don't know how feasible something like this would
>> be but I would find the following terribly useful.
>>
>> A properties hierarchy much like Maven that permits you to specify a
>> parent that you inherit from and then can add to or override.
>>
>> com.foo.parent.cfg
>> com.foo.child.cfg
>>
>> The child cfg file might have a #! directive at the top specifying
>> com.foo.parent PID. And if another one was
>>
>> com.foo.grandchild.cfg
>>
>> it might specify com.foo.child as its parent. Then the CM would load
>> parent, override it with child and finally override that grahdchild.
>>
>> Yes, I'd still have to specify
>>
>> <cm:property-placeholder persistent-id="com.foo.granchild"
>> update-strategy="reload">
>>
>> in my bundle and that would still be bound to that single bundle but this
>> could alleviate the need for replication of properties across a lot of
>> bundles.
>>
>> Technically that is all rather straightforward but I'm not sure how well
>> that would align with the specifications or goals of CM.
>>
>> Brad
>>
>
>
