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 <[email protected]> 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 <[email protected]> > 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 <[email protected] > > 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 <[email protected]> >> 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 < >>> [email protected]> wrote: >>> > >>> > As I work in more environments now that want to use microservices the >>> limitations of the blueprint properties mechanics become a bit hairier. I >>> commonly find that I have bundles that have common properties shared across >>> them and I can't find a good solution other than creating my own OSGi >>> service for serving them up for such crosscutting concerns. >>> > >>> > I'm not an expert on the specification and implementations of >>> compendium or blueprint libraries so don't know how feasible something like >>> this would be but I would find the following terribly useful. >>> > >>> > A properties hierarchy much like Maven that permits you to specify a >>> parent that you inherit from and then can add to or override. >>> > >>> > com.foo.parent.cfg >>> > com.foo.child.cfg >>> > >>> > The child cfg file might have a #! directive at the top specifying >>> com.foo.parent PID. And if another one was >>> > >>> > com.foo.grandchild.cfg >>> > >>> > it might specify com.foo.child as its parent. Then the CM would load >>> parent, override it with child and finally override that grahdchild. >>> > >>> > Yes, I'd still have to specify >>> > >>> > <cm:property-placeholder persistent-id="com.foo.granchild" >>> update-strategy="reload"> >>> > >>> > in my bundle and that would still be bound to that single bundle but >>> this could alleviate the need for replication of properties across a lot of >>> bundles. >>> > >>> > Technically that is all rather straightforward but I'm not sure how >>> well that would align with the specifications or goals of CM. >>> > >>> > Brad >>> >>> >> > >
