I think one really big problem with the OSGi specs is that only people
working for an OSGi alliance member can work on specs.
Especially in the open source world there are a lot of motivated people
with good knowledge but if their employer is not an OSGi member these
people can not work on any spec.
So while I can understand that only the OSGi members decide about the
specs in the end I think the OSGi alliance must open itself more for
individuals who are offering to help. Only in this way
the OSGi alliance can keep up with the dynamics of open source.
Having saig all this I am not sure though if it would really help with
blueprint. In the case of blueprint my impression is that it has grown
too complex while still having some severe drawbacks in practice.
So I myself are currently looking more into DS as it is simpler and has
less issues with all the OSGi dynamics. I think DS might need a defined
extension model but in its core I really like that
it kept being quite simple.
Christian
On 08.07.2016 12:37, David Bosschaert wrote:
Hi Brad,
On the 'Blueprint is dead' discussion... There are a number of RFCs in
OSGi about improving blueprint [1][2][3][4][5], but they have not made
it to the specs yet because those pushing them forward ended up being
reassigned to other work. Anyone who is a member of OSGi can certainly
pick those up and bring 'Blueprint back to life'... OTOH a lot of work
has gone into Declarative Services over the recent past so if someone
was to start from scratch it would make most sense to use DS today...
Best regards,
David
[1] https://github.com/osgi/design/tree/master/rfcs/rfc0155
[2] https://github.com/osgi/design/tree/master/rfcs/rfc0156
[3] https://github.com/osgi/design/tree/master/rfcs/rfc0164
[4] https://github.com/osgi/design/tree/master/rfcs/rfc0166
[5] https://github.com/osgi/design/tree/master/rfcs/rfc0184
On 8 July 2016 at 11:24, Brad Johnson <[email protected]
<mailto:[email protected]>> wrote:
David B,
Thanks. Part of the reason I brought this to this thread was
another gentleman on the Camel mailing list was trying to figure
out how to share configurations across his bundles and wondered if
the PID mechanics of blueprint were usable or if there were a way
to do it via blueprint. David J pointed out that the
multilocation mechanism was the way. But I hadn't heard of that
being implemented or available via blueprint. That's when the
"blueprint is dead" discussion started.
Brad
On Fri, Jul 8, 2016 at 3:50 AM, David Bosschaert
<[email protected] <mailto:[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]
<mailto:[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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
