Properties cfg wish...

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Properties cfg wish...

Brad Johnson
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
Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

David Jencks
I strongly suggest that you work on this in the context of an OSGI RFP/RFC.  You are apt to get much better advice that conducting the design discussion here.  I think it’s fairly ridiculous that after all these years blueprint’s relationship to config admin is unspecified.  I think that there are no “blueprint people” other than users these days.

I would also suggest studying at least the R6 config admin spec and understanding multi locations as that will make it clear that blueprint shouldn’t have anything explicit to do with bundle locations and that your concerns about sharing configuration across bundles have been dealt with in the appropriate spec already.

In addition I suggest studying the DS R6 multiple pid support as a possible model for what you are interested in.  I don’t think your apparent idea of using pid name parsing as the way of relating multiple pids is very scalable or comprehensible.

On the other hand, you could approach this all from a management agent perspective and have the management agent merge configuration source data with related “names" into a single configuration.  This would work with current blueprint cm.

I think that merging data in config admin is an untenable approach.  It certainly wasn’t the approach adopted for DS, and I would think getting spec support for it would be difficult.

david jencks


> On Jul 7, 2016, at 10:53 AM, Brad Johnson <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

Brad Johnson
As I said on the Camel mailing list Red Hat isn't pushing that approach and I can't push my clients into things they don't want.  You and Scott England Sullivan seem to be the ones who think that DS is going to save the world.  I have a number of friends in consultancy both inside and outside Red Hat and they don't like or push DS.

On Thu, Jul 7, 2016 at 2:30 PM, David Jencks <[hidden email]> wrote:
I strongly suggest that you work on this in the context of an OSGI RFP/RFC.  You are apt to get much better advice that conducting the design discussion here.  I think it’s fairly ridiculous that after all these years blueprint’s relationship to config admin is unspecified.  I think that there are no “blueprint people” other than users these days.

I would also suggest studying at least the R6 config admin spec and understanding multi locations as that will make it clear that blueprint shouldn’t have anything explicit to do with bundle locations and that your concerns about sharing configuration across bundles have been dealt with in the appropriate spec already.

In addition I suggest studying the DS R6 multiple pid support as a possible model for what you are interested in.  I don’t think your apparent idea of using pid name parsing as the way of relating multiple pids is very scalable or comprehensible.

On the other hand, you could approach this all from a management agent perspective and have the management agent merge configuration source data with related “names" into a single configuration.  This would work with current blueprint cm.

I think that merging data in config admin is an untenable approach.  It certainly wasn’t the approach adopted for DS, and I would think getting spec support for it would be difficult.

david jencks


> On Jul 7, 2016, at 10:53 AM, Brad Johnson <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

Brad Johnson
Isn't this the Aries discussion forum which has a Blueprint implementation?  Why would this be the incorrect place to ask about such issues?

On Thu, Jul 7, 2016 at 2:34 PM, Brad Johnson <[hidden email]> wrote:
As I said on the Camel mailing list Red Hat isn't pushing that approach and I can't push my clients into things they don't want.  You and Scott England Sullivan seem to be the ones who think that DS is going to save the world.  I have a number of friends in consultancy both inside and outside Red Hat and they don't like or push DS.

On Thu, Jul 7, 2016 at 2:30 PM, David Jencks <[hidden email]> wrote:
I strongly suggest that you work on this in the context of an OSGI RFP/RFC.  You are apt to get much better advice that conducting the design discussion here.  I think it’s fairly ridiculous that after all these years blueprint’s relationship to config admin is unspecified.  I think that there are no “blueprint people” other than users these days.

I would also suggest studying at least the R6 config admin spec and understanding multi locations as that will make it clear that blueprint shouldn’t have anything explicit to do with bundle locations and that your concerns about sharing configuration across bundles have been dealt with in the appropriate spec already.

In addition I suggest studying the DS R6 multiple pid support as a possible model for what you are interested in.  I don’t think your apparent idea of using pid name parsing as the way of relating multiple pids is very scalable or comprehensible.

On the other hand, you could approach this all from a management agent perspective and have the management agent merge configuration source data with related “names" into a single configuration.  This would work with current blueprint cm.

I think that merging data in config admin is an untenable approach.  It certainly wasn’t the approach adopted for DS, and I would think getting spec support for it would be difficult.

david jencks


> On Jul 7, 2016, at 10:53 AM, Brad Johnson <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

David Jencks
Well, its the user list rather than dev list, but that’s minor.

My point is that you are suggesting designing some new functionality for (possibly) blueprint.  I suggest that if you want to end up with a good design, you get osgi experts involved.  In my experience this results in a much improved design over what I can come up with by myself.

You are also telling me that blueprint is very popular among osgi users.  My personal impression from working on osgi specs is that blueprint is regarded as basically dead as there has been no spec activity since IBM pushed the original spec.  Getting involved in updating the blueprint spec for R7 might be a good way to popularize the benefits of blueprint — just because I don’t see them doesn’t mean they aren’t there.

Finally, I’m not convinced that you have a good understanding of the different services and their currently specified behavior.  If multi-location solves your problem and you are on R4.2 the solution is not to reinvent it for R4.2 or blueprint but to upgrade to R5+.

thanks
david jencks

On Jul 7, 2016, at 12:38 PM, Brad Johnson <[hidden email]> wrote:

Isn't this the Aries discussion forum which has a Blueprint implementation?  Why would this be the incorrect place to ask about such issues?

On Thu, Jul 7, 2016 at 2:34 PM, Brad Johnson <[hidden email]> wrote:
As I said on the Camel mailing list Red Hat isn't pushing that approach and I can't push my clients into things they don't want.  You and Scott England Sullivan seem to be the ones who think that DS is going to save the world.  I have a number of friends in consultancy both inside and outside Red Hat and they don't like or push DS.

On Thu, Jul 7, 2016 at 2:30 PM, David Jencks <[hidden email]> wrote:
I strongly suggest that you work on this in the context of an OSGI RFP/RFC.  You are apt to get much better advice that conducting the design discussion here.  I think it’s fairly ridiculous that after all these years blueprint’s relationship to config admin is unspecified.  I think that there are no “blueprint people” other than users these days.

I would also suggest studying at least the R6 config admin spec and understanding multi locations as that will make it clear that blueprint shouldn’t have anything explicit to do with bundle locations and that your concerns about sharing configuration across bundles have been dealt with in the appropriate spec already.

In addition I suggest studying the DS R6 multiple pid support as a possible model for what you are interested in.  I don’t think your apparent idea of using pid name parsing as the way of relating multiple pids is very scalable or comprehensible.

On the other hand, you could approach this all from a management agent perspective and have the management agent merge configuration source data with related “names" into a single configuration.  This would work with current blueprint cm.

I think that merging data in config admin is an untenable approach.  It certainly wasn’t the approach adopted for DS, and I would think getting spec support for it would be difficult.

david jencks


> On Jul 7, 2016, at 10:53 AM, Brad Johnson <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

Brad Johnson
Interesting that there should be such a discrepancy from what I see in the field and the specification work that's going on.  If you look at the releases related to Aries, for example, the multiple blueprint projects have had multiple releases and updates this past year. Just looking at the Maven repo shows an incredible amount of activity.  The Blueprint CM 1.0.8 was just released this March. 

I sound like a blueprint advocate but I'm not really. I actually loathe working in XML. Believe me I've had a few years of blueprint headaches and have more than enough complaints about it.  I just need pragmatic ways of wiring Camel and OSGi services together for enterprise applications with the dependency injection and OSGi interoperability and Camel EIPs that blueprint provides.  If something better comes along then great, I'm all for it.

But I've also had enough experience withe Camel Java route builders to not really want to get into them again (despite the advantages in the IDE). And SCR annotations are pretty ugly quite frankly (I know, everyone has their own opinion of that).  While I find the debate about proxy versus cascading services mildly interesting from an intellectual standpoint it isn't of tremendous importance to me.  What is important to me is that my EIPs and routes work when I'm counting on a service reference being available.  But I guess I can always dip into service order start up to hopefully make such guarantees. 

Perhaps someday when someone writes that enterprise Camel with SCR book that makes it all easy and great in the day-to-day enterprise development world with CXF, JMS, Hibernate and so I'll flip to declarative services and abandon Blueprint.  In the meantime I'm stuck with it as a tool.

Frankly if DS is the only game in town for the future then perhaps it'll be time to explore the wider world of technologies.



On Thu, Jul 7, 2016 at 4:48 PM, David Jencks <[hidden email]> wrote:
Well, its the user list rather than dev list, but that’s minor.

My point is that you are suggesting designing some new functionality for (possibly) blueprint.  I suggest that if you want to end up with a good design, you get osgi experts involved.  In my experience this results in a much improved design over what I can come up with by myself.

You are also telling me that blueprint is very popular among osgi users.  My personal impression from working on osgi specs is that blueprint is regarded as basically dead as there has been no spec activity since IBM pushed the original spec.  Getting involved in updating the blueprint spec for R7 might be a good way to popularize the benefits of blueprint — just because I don’t see them doesn’t mean they aren’t there.

Finally, I’m not convinced that you have a good understanding of the different services and their currently specified behavior.  If multi-location solves your problem and you are on R4.2 the solution is not to reinvent it for R4.2 or blueprint but to upgrade to R5+.

thanks
david jencks

On Jul 7, 2016, at 12:38 PM, Brad Johnson <[hidden email]> wrote:

Isn't this the Aries discussion forum which has a Blueprint implementation?  Why would this be the incorrect place to ask about such issues?

On Thu, Jul 7, 2016 at 2:34 PM, Brad Johnson <[hidden email]> wrote:
As I said on the Camel mailing list Red Hat isn't pushing that approach and I can't push my clients into things they don't want.  You and Scott England Sullivan seem to be the ones who think that DS is going to save the world.  I have a number of friends in consultancy both inside and outside Red Hat and they don't like or push DS.

On Thu, Jul 7, 2016 at 2:30 PM, David Jencks <[hidden email]> wrote:
I strongly suggest that you work on this in the context of an OSGI RFP/RFC.  You are apt to get much better advice that conducting the design discussion here.  I think it’s fairly ridiculous that after all these years blueprint’s relationship to config admin is unspecified.  I think that there are no “blueprint people” other than users these days.

I would also suggest studying at least the R6 config admin spec and understanding multi locations as that will make it clear that blueprint shouldn’t have anything explicit to do with bundle locations and that your concerns about sharing configuration across bundles have been dealt with in the appropriate spec already.

In addition I suggest studying the DS R6 multiple pid support as a possible model for what you are interested in.  I don’t think your apparent idea of using pid name parsing as the way of relating multiple pids is very scalable or comprehensible.

On the other hand, you could approach this all from a management agent perspective and have the management agent merge configuration source data with related “names" into a single configuration.  This would work with current blueprint cm.

I think that merging data in config admin is an untenable approach.  It certainly wasn’t the approach adopted for DS, and I would think getting spec support for it would be difficult.

david jencks


> On Jul 7, 2016, at 10:53 AM, Brad Johnson <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

David Jencks
Possibly the lack of spec activity on blueprint is because there is only one implementation.  However if I were using blueprint I’d be pretty worried that something as essential as cm support isn’t in the spec.  Thus, I’m trying to encourage blueprint users to help get it there….

From the original idea of merging data from input files with related names into configuration for one blueprint “thing” I think the most appropriate solution would be a management agent (like enhanced fileinstall) that merged the data before turning it into a configuration.  This wouldn’t require any change in blueprint.

On the other hand I think a blueprint feature like DS has of support for multiple pids would be pretty useful.  Since cm support isn’t spec, someone could just implement it.  I’d think that getting it in a spec would lend it a little more credibility.

I’m curious what it is you don’t like about (the R6 spec) DS annotations.  I think it’s extremely slick to be able to configure your component with an annotation and annotate that annotation to get the metatype that describes the configuration.  As far as I know with updated bnd you don’t need to specify any duplicate information, which is fairly new :-).

Service order startup is not a reliable way to get anything to work in osgi :-)  Mandatory references work pretty well, and if you need several of one kind of thing the <refname>.cardinality.minimum property works great with DS.

It sounds like as a DS partisan I should investigate camel and figure out a good DS way to come up with a route :-)

thanks
david jencks

On Jul 7, 2016, at 4:08 PM, Brad Johnson <[hidden email]> wrote:

Interesting that there should be such a discrepancy from what I see in the field and the specification work that's going on.  If you look at the releases related to Aries, for example, the multiple blueprint projects have had multiple releases and updates this past year. Just looking at the Maven repo shows an incredible amount of activity.  The Blueprint CM 1.0.8 was just released this March. 

I sound like a blueprint advocate but I'm not really. I actually loathe working in XML. Believe me I've had a few years of blueprint headaches and have more than enough complaints about it.  I just need pragmatic ways of wiring Camel and OSGi services together for enterprise applications with the dependency injection and OSGi interoperability and Camel EIPs that blueprint provides.  If something better comes along then great, I'm all for it.

But I've also had enough experience withe Camel Java route builders to not really want to get into them again (despite the advantages in the IDE). And SCR annotations are pretty ugly quite frankly (I know, everyone has their own opinion of that).  While I find the debate about proxy versus cascading services mildly interesting from an intellectual standpoint it isn't of tremendous importance to me.  What is important to me is that my EIPs and routes work when I'm counting on a service reference being available.  But I guess I can always dip into service order start up to hopefully make such guarantees. 

Perhaps someday when someone writes that enterprise Camel with SCR book that makes it all easy and great in the day-to-day enterprise development world with CXF, JMS, Hibernate and so I'll flip to declarative services and abandon Blueprint.  In the meantime I'm stuck with it as a tool.

Frankly if DS is the only game in town for the future then perhaps it'll be time to explore the wider world of technologies.



On Thu, Jul 7, 2016 at 4:48 PM, David Jencks <[hidden email]> wrote:
Well, its the user list rather than dev list, but that’s minor.

My point is that you are suggesting designing some new functionality for (possibly) blueprint.  I suggest that if you want to end up with a good design, you get osgi experts involved.  In my experience this results in a much improved design over what I can come up with by myself.

You are also telling me that blueprint is very popular among osgi users.  My personal impression from working on osgi specs is that blueprint is regarded as basically dead as there has been no spec activity since IBM pushed the original spec.  Getting involved in updating the blueprint spec for R7 might be a good way to popularize the benefits of blueprint — just because I don’t see them doesn’t mean they aren’t there.

Finally, I’m not convinced that you have a good understanding of the different services and their currently specified behavior.  If multi-location solves your problem and you are on R4.2 the solution is not to reinvent it for R4.2 or blueprint but to upgrade to R5+.

thanks
david jencks

On Jul 7, 2016, at 12:38 PM, Brad Johnson <[hidden email]> wrote:

Isn't this the Aries discussion forum which has a Blueprint implementation?  Why would this be the incorrect place to ask about such issues?

On Thu, Jul 7, 2016 at 2:34 PM, Brad Johnson <[hidden email]> wrote:
As I said on the Camel mailing list Red Hat isn't pushing that approach and I can't push my clients into things they don't want.  You and Scott England Sullivan seem to be the ones who think that DS is going to save the world.  I have a number of friends in consultancy both inside and outside Red Hat and they don't like or push DS.

On Thu, Jul 7, 2016 at 2:30 PM, David Jencks <[hidden email]> wrote:
I strongly suggest that you work on this in the context of an OSGI RFP/RFC.  You are apt to get much better advice that conducting the design discussion here.  I think it’s fairly ridiculous that after all these years blueprint’s relationship to config admin is unspecified.  I think that there are no “blueprint people” other than users these days.

I would also suggest studying at least the R6 config admin spec and understanding multi locations as that will make it clear that blueprint shouldn’t have anything explicit to do with bundle locations and that your concerns about sharing configuration across bundles have been dealt with in the appropriate spec already.

In addition I suggest studying the DS R6 multiple pid support as a possible model for what you are interested in.  I don’t think your apparent idea of using pid name parsing as the way of relating multiple pids is very scalable or comprehensible.

On the other hand, you could approach this all from a management agent perspective and have the management agent merge configuration source data with related “names" into a single configuration.  This would work with current blueprint cm.

I think that merging data in config admin is an untenable approach.  It certainly wasn’t the approach adopted for DS, and I would think getting spec support for it would be difficult.

david jencks


> On Jul 7, 2016, at 10:53 AM, Brad Johnson <[hidden email]> 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






Reply | Threaded
Open this post in threaded view
|

RE: Properties cfg wish...

CLEMENT Jean-Philippe
In reply to this post by David Jencks

I didn’t read all the thread but basically for your “blueprint is regarded as basically dead as there has been no spec activity”, I don’t catch the point. We use blueprint just to wire; the spec is enough for our needs. What’s the relationship between blueprint usage and its spec upgrade?

 

Regards,

Jean-Philippe

 

De : David Jencks [mailto:[hidden email]]
Envoyé : jeudi 7 juillet 2016 23:48
À : [hidden email]
Objet : Re: Properties cfg wish...

 

Well, its the user list rather than dev list, but that’s minor.

 

My point is that you are suggesting designing some new functionality for (possibly) blueprint.  I suggest that if you want to end up with a good design, you get osgi experts involved.  In my experience this results in a much improved design over what I can come up with by myself.

 

You are also telling me that blueprint is very popular among osgi users.  My personal impression from working on osgi specs is that blueprint is regarded as basically dead as there has been no spec activity since IBM pushed the original spec.  Getting involved in updating the blueprint spec for R7 might be a good way to popularize the benefits of blueprint — just because I don’t see them doesn’t mean they aren’t there.

 

Finally, I’m not convinced that you have a good understanding of the different services and their currently specified behavior.  If multi-location solves your problem and you are on R4.2 the solution is not to reinvent it for R4.2 or blueprint but to upgrade to R5+.

 

thanks

david jencks

 

On Jul 7, 2016, at 12:38 PM, Brad Johnson <[hidden email]> wrote:

 

Isn't this the Aries discussion forum which has a Blueprint implementation?  Why would this be the incorrect place to ask about such issues?

 

On Thu, Jul 7, 2016 at 2:34 PM, Brad Johnson <[hidden email]> wrote:

As I said on the Camel mailing list Red Hat isn't pushing that approach and I can't push my clients into things they don't want.  You and Scott England Sullivan seem to be the ones who think that DS is going to save the world.  I have a number of friends in consultancy both inside and outside Red Hat and they don't like or push DS.

 

On Thu, Jul 7, 2016 at 2:30 PM, David Jencks <[hidden email]> wrote:

I strongly suggest that you work on this in the context of an OSGI RFP/RFC.  You are apt to get much better advice that conducting the design discussion here.  I think it’s fairly ridiculous that after all these years blueprint’s relationship to config admin is unspecified.  I think that there are no “blueprint people” other than users these days.

I would also suggest studying at least the R6 config admin spec and understanding multi locations as that will make it clear that blueprint shouldn’t have anything explicit to do with bundle locations and that your concerns about sharing configuration across bundles have been dealt with in the appropriate spec already.

In addition I suggest studying the DS R6 multiple pid support as a possible model for what you are interested in.  I don’t think your apparent idea of using pid name parsing as the way of relating multiple pids is very scalable or comprehensible.

On the other hand, you could approach this all from a management agent perspective and have the management agent merge configuration source data with related “names" into a single configuration.  This would work with current blueprint cm.

I think that merging data in config admin is an untenable approach.  It certainly wasn’t the approach adopted for DS, and I would think getting spec support for it would be difficult.

david jencks



> On Jul 7, 2016, at 10:53 AM, Brad Johnson <[hidden email]> 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

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

David Bosschaert
In reply to this post by Brad Johnson
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

Dmytro Pishchukhin
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 <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

David Bosschaert
Hi Dmytro,

The OSGi MetaType Service (spec chapter 105) can provide some validation. It supports data types, ranges and discreet values and some other things...
Would this work for you? 

Best regards,

David

On 8 July 2016 at 10:04, Dmytro Pishchukhin <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

Brad Johnson
In reply to this post by David Bosschaert
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 <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

David Bosschaert
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


On 8 July 2016 at 11:24, Brad Johnson <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

Brad Johnson
In reply to this post by David Jencks
David J,

Upgrading to R5 doesn't solve the problem for Fuse/blueprint and the use of multilocations especially if they don't work with blueprint in any case.  The feature /I was suggesting wouldn't necessitate a specification upgrade through the OSGi community especially if blueprint is considered dead there.  This is a relatively simple idea on chaining configurations and an implementation option.  And, yeah, I probably should have posted this to dev and not users mailing list.

It's not clear to me why Red Hat has been dragging its feet on moving up from earlier versions of the specification in Fuse. Karaf is still at 2.x for example in Fuse. 

Until this past year the use of cross-cutting properties for bundles hasn't been a big deal.  But I'm running into more clients who want microservices and shared properties becomes more important.  If the multilocation made that work and were in blueprint that'd be great.

In my case blueprint is usually what I use for wiring up Camel routes, grabbing service references that are cross-cutting concerns, and setting properties.  I see DS/SCR as a cross-cutting concern there.  



On Thu, Jul 7, 2016 at 4:48 PM, David Jencks <[hidden email]> wrote:
Well, its the user list rather than dev list, but that’s minor.

My point is that you are suggesting designing some new functionality for (possibly) blueprint.  I suggest that if you want to end up with a good design, you get osgi experts involved.  In my experience this results in a much improved design over what I can come up with by myself.

You are also telling me that blueprint is very popular among osgi users.  My personal impression from working on osgi specs is that blueprint is regarded as basically dead as there has been no spec activity since IBM pushed the original spec.  Getting involved in updating the blueprint spec for R7 might be a good way to popularize the benefits of blueprint — just because I don’t see them doesn’t mean they aren’t there.

Finally, I’m not convinced that you have a good understanding of the different services and their currently specified behavior.  If multi-location solves your problem and you are on R4.2 the solution is not to reinvent it for R4.2 or blueprint but to upgrade to R5+.

thanks
david jencks

On Jul 7, 2016, at 12:38 PM, Brad Johnson <[hidden email]> wrote:

Isn't this the Aries discussion forum which has a Blueprint implementation?  Why would this be the incorrect place to ask about such issues?

On Thu, Jul 7, 2016 at 2:34 PM, Brad Johnson <[hidden email]> wrote:
As I said on the Camel mailing list Red Hat isn't pushing that approach and I can't push my clients into things they don't want.  You and Scott England Sullivan seem to be the ones who think that DS is going to save the world.  I have a number of friends in consultancy both inside and outside Red Hat and they don't like or push DS.

On Thu, Jul 7, 2016 at 2:30 PM, David Jencks <[hidden email]> wrote:
I strongly suggest that you work on this in the context of an OSGI RFP/RFC.  You are apt to get much better advice that conducting the design discussion here.  I think it’s fairly ridiculous that after all these years blueprint’s relationship to config admin is unspecified.  I think that there are no “blueprint people” other than users these days.

I would also suggest studying at least the R6 config admin spec and understanding multi locations as that will make it clear that blueprint shouldn’t have anything explicit to do with bundle locations and that your concerns about sharing configuration across bundles have been dealt with in the appropriate spec already.

In addition I suggest studying the DS R6 multiple pid support as a possible model for what you are interested in.  I don’t think your apparent idea of using pid name parsing as the way of relating multiple pids is very scalable or comprehensible.

On the other hand, you could approach this all from a management agent perspective and have the management agent merge configuration source data with related “names" into a single configuration.  This would work with current blueprint cm.

I think that merging data in config admin is an untenable approach.  It certainly wasn’t the approach adopted for DS, and I would think getting spec support for it would be difficult.

david jencks


> On Jul 7, 2016, at 10:53 AM, Brad Johnson <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

Christian Schneider
In reply to this post by David Jencks
I would greatly appreciate if you could look into a better way of combining camel with DS.

I recently tried to make camel work with DS and found that the DS support camel provides is quite complex and does not work well.
See http://camel.apache.org/camel-and-scr.html
The problem are the camel components. These are announced as services and must be available before you start the camel context.
The camel scr AbstractCamelRunner needs a lot of config to run and still is not correct. The problem is that it simply adds and removes the components at runtime
but once the camel context starts it is too late to add a component.
You will not notice the problem in karaf as karaf has very specific start level settings for the components to make sure they come up early but this sucks.

I have used a different approach for a demo:
https://github.com/cschneider/osgi-chat/blob/master/irc/src/main/java/net/lr/demo/chat/irc/IRCConnector.java
I simply add mandatory references to all components I use. So DS makes sure my component only comes up once everything is in place and also stops when some component is missing.
This works fine but is a bit inconvenient. Maybe you have a better idea how to do this.

Btw. For CXF support I currently work on improvements for Remote Service Admin with CXF as a provider I think this is currently the best way to use CXF in DS but we have to make sure it covers
all use cases people have. The CXF blueprint support allows a lot of settings and we have to make sure the RSA support can also offer all the needed customizations.
Hibernate support works quite well now with Aries JPA and JPATemplate or alternatively with Aries tx-control.

Christian


On 08.07.2016 02:49, David Jencks wrote:

It sounds like as a DS partisan I should investigate camel and figure out a good DS way to come up with a route :-)

thanks
david jencks

On Jul 7, 2016, at 4:08 PM, Brad Johnson <[hidden email]> wrote:

Interesting that there should be such a discrepancy from what I see in the field and the specification work that's going on.  If you look at the releases related to Aries, for example, the multiple blueprint projects have had multiple releases and updates this past year. Just looking at the Maven repo shows an incredible amount of activity.  The Blueprint CM 1.0.8 was just released this March. 

I sound like a blueprint advocate but I'm not really. I actually loathe working in XML. Believe me I've had a few years of blueprint headaches and have more than enough complaints about it.  I just need pragmatic ways of wiring Camel and OSGi services together for enterprise applications with the dependency injection and OSGi interoperability and Camel EIPs that blueprint provides.  If something better comes along then great, I'm all for it.

But I've also had enough experience withe Camel Java route builders to not really want to get into them again (despite the advantages in the IDE). And SCR annotations are pretty ugly quite frankly (I know, everyone has their own opinion of that).  While I find the debate about proxy versus cascading services mildly interesting from an intellectual standpoint it isn't of tremendous importance to me.  What is important to me is that my EIPs and routes work when I'm counting on a service reference being available.  But I guess I can always dip into service order start up to hopefully make such guarantees. 

Perhaps someday when someone writes that enterprise Camel with SCR book that makes it all easy and great in the day-to-day enterprise development world with CXF, JMS, Hibernate and so I'll flip to declarative services and abandon Blueprint.  In the meantime I'm stuck with it as a tool.

Frankly if DS is the only game in town for the future then perhaps it'll be time to explore the wider world of technologies.



On Thu, Jul 7, 2016 at 4:48 PM, David Jencks <[hidden email]> wrote:
Well, its the user list rather than dev list, but that’s minor.

My point is that you are suggesting designing some new functionality for (possibly) blueprint.  I suggest that if you want to end up with a good design, you get osgi experts involved.  In my experience this results in a much improved design over what I can come up with by myself.

You are also telling me that blueprint is very popular among osgi users.  My personal impression from working on osgi specs is that blueprint is regarded as basically dead as there has been no spec activity since IBM pushed the original spec.  Getting involved in updating the blueprint spec for R7 might be a good way to popularize the benefits of blueprint — just because I don’t see them doesn’t mean they aren’t there.

Finally, I’m not convinced that you have a good understanding of the different services and their currently specified behavior.  If multi-location solves your problem and you are on R4.2 the solution is not to reinvent it for R4.2 or blueprint but to upgrade to R5+.

thanks
david jencks

On Jul 7, 2016, at 12:38 PM, Brad Johnson <[hidden email]> wrote:

Isn't this the Aries discussion forum which has a Blueprint implementation?  Why would this be the incorrect place to ask about such issues?

On Thu, Jul 7, 2016 at 2:34 PM, Brad Johnson <[hidden email]> wrote:
As I said on the Camel mailing list Red Hat isn't pushing that approach and I can't push my clients into things they don't want.  You and Scott England Sullivan seem to be the ones who think that DS is going to save the world.  I have a number of friends in consultancy both inside and outside Red Hat and they don't like or push DS.

On Thu, Jul 7, 2016 at 2:30 PM, David Jencks <[hidden email]> wrote:
I strongly suggest that you work on this in the context of an OSGI RFP/RFC.  You are apt to get much better advice that conducting the design discussion here.  I think it’s fairly ridiculous that after all these years blueprint’s relationship to config admin is unspecified.  I think that there are no “blueprint people” other than users these days.

I would also suggest studying at least the R6 config admin spec and understanding multi locations as that will make it clear that blueprint shouldn’t have anything explicit to do with bundle locations and that your concerns about sharing configuration across bundles have been dealt with in the appropriate spec already.

In addition I suggest studying the DS R6 multiple pid support as a possible model for what you are interested in.  I don’t think your apparent idea of using pid name parsing as the way of relating multiple pids is very scalable or comprehensible.

On the other hand, you could approach this all from a management agent perspective and have the management agent merge configuration source data with related “names" into a single configuration.  This would work with current blueprint cm.

I think that merging data in config admin is an untenable approach.  It certainly wasn’t the approach adopted for DS, and I would think getting spec support for it would be difficult.

david jencks


> On Jul 7, 2016, at 10:53 AM, Brad Johnson <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

Brad Johnson
In reply to this post by David Bosschaert
I'd echo your earlier comment about being a bit confused about the "blueprint is dead" when it seems to be orthogonal in its concerns to what DS.  Configuration Management may be a place where they significantly overlap but I'm using Blueprint as an OSGi aware Spring for dependency injection and Camel routes, including endpoint set up for CXF, JMS, etc, and for data converter set up.  The CM lack of shared properties in blueprint is a problem and I've resorted to using my own OSGi services in some case to make such common values available.  A hack to be sure...

If Blueprint is considered dead then I'd have to rethink my road ahead.  

If I look to my own personal preferences in the future I'll go away from more monolithic stacks like Fuse and more toward the Karaf 4 profiles to create appliances that might be small business processes or even microservices themselves.  While that will use a bit more memory and system resources I don't see that as much of a problem in today's enterprise world and the benefits can be tremendous.  For me that kills a lot of birds with one stone.  But on a professional level for the time I don't have that sort of freedom currently.


On Fri, Jul 8, 2016 at 5:37 AM, David Bosschaert <[hidden email]> 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


On 8 July 2016 at 11:24, Brad Johnson <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

Christian Schneider
In reply to this post by David Bosschaert
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


On 8 July 2016 at 11:24, Brad Johnson <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

Brad Johnson
In reply to this post by Christian Schneider
Christian,

Perhaps that's why my view of DS isn't as sunny as it could be since I use Camel extensively and did not have great experiences with it and DS.  While I know that proxies have their downside and that chaining is preferable, proxies ensure that Camel has what it needs when it runs.  When I fire up Fuse with 800 bundles the thought of having to manage start up orders as one more configuration chore is a bit depressing. 

I'm very much looking forward to when I can do more work with Karaf 4 and profiles.  For most of my clients they are in Fuse back in 2.x however.

Brad

On Fri, Jul 8, 2016 at 5:54 AM, Christian Schneider <[hidden email]> wrote:
I would greatly appreciate if you could look into a better way of combining camel with DS.

I recently tried to make camel work with DS and found that the DS support camel provides is quite complex and does not work well.
See http://camel.apache.org/camel-and-scr.html
The problem are the camel components. These are announced as services and must be available before you start the camel context.
The camel scr AbstractCamelRunner needs a lot of config to run and still is not correct. The problem is that it simply adds and removes the components at runtime
but once the camel context starts it is too late to add a component.
You will not notice the problem in karaf as karaf has very specific start level settings for the components to make sure they come up early but this sucks.

I have used a different approach for a demo:
https://github.com/cschneider/osgi-chat/blob/master/irc/src/main/java/net/lr/demo/chat/irc/IRCConnector.java
I simply add mandatory references to all components I use. So DS makes sure my component only comes up once everything is in place and also stops when some component is missing.
This works fine but is a bit inconvenient. Maybe you have a better idea how to do this.

Btw. For CXF support I currently work on improvements for Remote Service Admin with CXF as a provider I think this is currently the best way to use CXF in DS but we have to make sure it covers
all use cases people have. The CXF blueprint support allows a lot of settings and we have to make sure the RSA support can also offer all the needed customizations.
Hibernate support works quite well now with Aries JPA and JPATemplate or alternatively with Aries tx-control.

Christian



On 08.07.2016 02:49, David Jencks wrote:

It sounds like as a DS partisan I should investigate camel and figure out a good DS way to come up with a route :-)

thanks
david jencks

On Jul 7, 2016, at 4:08 PM, Brad Johnson <[hidden email][hidden email]> wrote:

Interesting that there should be such a discrepancy from what I see in the field and the specification work that's going on.  If you look at the releases related to Aries, for example, the multiple blueprint projects have had multiple releases and updates this past year. Just looking at the Maven repo shows an incredible amount of activity.  The Blueprint CM 1.0.8 was just released this March. 

I sound like a blueprint advocate but I'm not really. I actually loathe working in XML. Believe me I've had a few years of blueprint headaches and have more than enough complaints about it.  I just need pragmatic ways of wiring Camel and OSGi services together for enterprise applications with the dependency injection and OSGi interoperability and Camel EIPs that blueprint provides.  If something better comes along then great, I'm all for it.

But I've also had enough experience withe Camel Java route builders to not really want to get into them again (despite the advantages in the IDE). And SCR annotations are pretty ugly quite frankly (I know, everyone has their own opinion of that).  While I find the debate about proxy versus cascading services mildly interesting from an intellectual standpoint it isn't of tremendous importance to me.  What is important to me is that my EIPs and routes work when I'm counting on a service reference being available.  But I guess I can always dip into service order start up to hopefully make such guarantees. 

Perhaps someday when someone writes that enterprise Camel with SCR book that makes it all easy and great in the day-to-day enterprise development world with CXF, JMS, Hibernate and so I'll flip to declarative services and abandon Blueprint.  In the meantime I'm stuck with it as a tool.

Frankly if DS is the only game in town for the future then perhaps it'll be time to explore the wider world of technologies.



On Thu, Jul 7, 2016 at 4:48 PM, David Jencks <[hidden email][hidden email]> wrote:
Well, its the user list rather than dev list, but that’s minor.

My point is that you are suggesting designing some new functionality for (possibly) blueprint.  I suggest that if you want to end up with a good design, you get osgi experts involved.  In my experience this results in a much improved design over what I can come up with by myself.

You are also telling me that blueprint is very popular among osgi users.  My personal impression from working on osgi specs is that blueprint is regarded as basically dead as there has been no spec activity since IBM pushed the original spec.  Getting involved in updating the blueprint spec for R7 might be a good way to popularize the benefits of blueprint — just because I don’t see them doesn’t mean they aren’t there.

Finally, I’m not convinced that you have a good understanding of the different services and their currently specified behavior.  If multi-location solves your problem and you are on R4.2 the solution is not to reinvent it for R4.2 or blueprint but to upgrade to R5+.

thanks
david jencks

On Jul 7, 2016, at 12:38 PM, Brad Johnson <[hidden email][hidden email]> wrote:

Isn't this the Aries discussion forum which has a Blueprint implementation?  Why would this be the incorrect place to ask about such issues?

On Thu, Jul 7, 2016 at 2:34 PM, Brad Johnson <[hidden email][hidden email]> wrote:
As I said on the Camel mailing list Red Hat isn't pushing that approach and I can't push my clients into things they don't want.  You and Scott England Sullivan seem to be the ones who think that DS is going to save the world.  I have a number of friends in consultancy both inside and outside Red Hat and they don't like or push DS.

On Thu, Jul 7, 2016 at 2:30 PM, David Jencks <[hidden email][hidden email]> wrote:
I strongly suggest that you work on this in the context of an OSGI RFP/RFC.  You are apt to get much better advice that conducting the design discussion here.  I think it’s fairly ridiculous that after all these years blueprint’s relationship to config admin is unspecified.  I think that there are no “blueprint people” other than users these days.

I would also suggest studying at least the R6 config admin spec and understanding multi locations as that will make it clear that blueprint shouldn’t have anything explicit to do with bundle locations and that your concerns about sharing configuration across bundles have been dealt with in the appropriate spec already.

In addition I suggest studying the DS R6 multiple pid support as a possible model for what you are interested in.  I don’t think your apparent idea of using pid name parsing as the way of relating multiple pids is very scalable or comprehensible.

On the other hand, you could approach this all from a management agent perspective and have the management agent merge configuration source data with related “names" into a single configuration.  This would work with current blueprint cm.

I think that merging data in config admin is an untenable approach.  It certainly wasn’t the approach adopted for DS, and I would think getting spec support for it would be difficult.

david jencks


> On Jul 7, 2016, at 10:53 AM, Brad Johnson <[hidden email][hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

Christian Schneider
 > proxies ensure that Camel has what it needs when it runs

Unfortunately this is not true. Camel only runs well because the defined
start levels start the components before your user bundles. This is a
very fragile approach though and totally breaks when not using karaf.
The core of the problem is that in camel you access a component by just
a String uri. If the component is present at the time the route starts
then this will work if not it will break.
As the dependency to the component is just a URI there is no way to use
static code analysis to make sure all necessary components are present.
So I am not sure how to solve this.

Christian

On 08.07.2016 13:05, Brad Johnson wrote:

> Christian,
>
> Perhaps that's why my view of DS isn't as sunny as it could be since I
> use Camel extensively and did not have great experiences with it and
> DS.  While I know that proxies have their downside and that chaining
> is preferable, proxies ensure that Camel has what it needs when it
> runs.  When I fire up Fuse with 800 bundles the thought of having to
> manage start up orders as one more configuration chore is a bit
> depressing.
>
> I'm very much looking forward to when I can do more work with Karaf 4
> and profiles.  For most of my clients they are in Fuse back in 2.x
> however.
>
> Brad
>

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Properties cfg wish...

Brad Johnson
In reply to this post by Christian Schneider
Christian,

I think one other problem with DS is that so much of the literature is about here's how to start up a component and why we should prefer that and how the annotations work.  In the enterprise world, as you are aware, we have a lot of concerns like how do I set up my CXF endpoint, DS, Camel routes, properties/cfg, ensure that my services are all accounted for when things run, have easy test-ability and deployment, versioning, etc.  The OSGi community has been so closely focused on DS that I wonder if that larger world and use case doesn't get lost.

I mean your comment says a lot: "I recently tried to make camel work with DS and found that the DS support camel provides is quite complex and does not work well."

Part of the issue there too is that Camel is a Swiss Army knife for both good and ill.  Reading through the documentation one has to be able to switch between reading XML and Java DSL and that feels like reading Latin and then switching to Greek.  That and there is something not quite right about the Camel Java DSL.  I'd love to be able to embrace it and have tried to on multiple occasions.  But recently I was working with it again and I always feel like I'm wearing a straight jacket with it.  You get stuck in the fluent builder.  As much as I dislike XML and working with it at least the flow feels right to me, a route is invoking logic on a Java handler in a typed fashion and that makes it easy to unit test.

On Fri, Jul 8, 2016 at 6:03 AM, Christian Schneider <[hidden email]> wrote:
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


On 8 July 2016 at 11:24, Brad Johnson <[hidden email]> 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 <[hidden email][hidden email]> 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 <[hidden email][hidden email]> 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

12