You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Brad Johnson <br...@mediadriver.com> on 2016/07/07 17:53:24 UTC
Properties cfg wish...
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
Re: Properties cfg wish...
Posted by David Bosschaert <da...@gmail.com>.
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 <dm...@gmail.com>
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 <
> david.bosschaert@gmail.com> 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 <br...@mediadriver.com>
>> 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
>>>
>>
>>
>
Re: Properties cfg wish...
Posted by Dmytro Pishchukhin <dm...@gmail.com>.
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 <
david.bosschaert@gmail.com> 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 <br...@mediadriver.com>
> 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
>>
>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
More succinctly:
parent.batch.cfg
children
parent.batch.dev.cfg
parent.batch.test.cfg
parent.batch.production.cfg
childeren
com.my.batch.transaction.cfg
com.my.batch.accountupdates.cfg
Would result in these files in the configuration bundle:
com.my.batch.transaction.dev.cfg
com.my.batch.accountupdates.dev.cfg
test and dev.
The features file would then be:
<feature name="dev.someproject" version="${project.version}">
<configfile finalname="/etc/com.my.batch.transactions.cfg"
override="true">mvn:com.someproject/config/${project.
version}/cfg/com.my.batch.transactions.dev</configfile>
<configfile finalname="/etc/com.my.batch.accountupdates.cfg"
override="true">mvn:com.someproject/config/${project.
version}/cfg/com.my.batch.accountupdates.dev</configfile>
...then call the feature to install the bundles...
I'd then have a compact way of specify shared properties in parents,
compiled into bundle and then installed via feature.
On Fri, Jul 8, 2016 at 9:22 AM, Brad Johnson <br...@mediadriver.com>
wrote:
> After getting into these discussions I started thinking that perhaps I'd
> move all the configuration files into one bundle and install them from
> features file that way. I could have dev/test/prod cfg files in that same
> bundle.
>
> Using a combination of filtered resources and some other mechanics then I
> can perhaps come up with a way so that
>
> com.my.batch.transaction.cfg
> com.my.batch.accountupdates.cfg
>
> have a com.my.batch.parent.cfg and during Maven build it is read into and
> made part of both the transaction and account updates.cfg files. Those are
> then put into the configuration bundle. When that configuration bundle is
> installed the PIDs/properties match the bundles looking for them but
> contain the common information as already been flattened into them.
>
> That configuration bundle could also have test/dev/production cfg files
> and the features file could permit installing test, dev or production the
> only difference being which set of configuration files they installed
> before installing the bundles themselves.
>
>
> On Fri, Jul 8, 2016 at 9:12 AM, Brad Johnson <brad.johnson@mediadriver.com
> > wrote:
>
>> Here's a small example. The two batch processes do very different things
>> yet share some common configuration information pertaining to directories,
>> ftp and service endpoints. That configuration information obviously also
>> varies between dev, test, and production. This is one small part of the
>> project. The connector project is already a crosscutting concern that
>> keeps its connection information separated from all the other business
>> processes/services that use it. Some of the properties have queue names
>> (SEDA or JMS) that are shared between bundles and use runtime substitution
>> in Camel. But duplicating configuration information between the bundles
>> and hand massaging it is error prone and makes refactoring a pain.
>>
>> <feature name="someproject" version="${project.version}">
>>
>> <configfile finalname="/etc/com.litle.cfg"
>> override="false">mvn:com.my.connectors/litle/${project.version}/cfg/configuration</configfile>
>> <configfile finalname="/etc/com.my.batch.transactions.cfg"
>> override="false">mvn:
>> com.my/batch.transactions/${project.version}/cfg/configuration
>> <http://com.my/batch.transactions/$%7Bproject.version%7D/cfg/configuration>
>> </configfile>
>> <configfile finalname="/etc/com.my.batch.accountupdates.cfg"
>> override="false">mvn:
>> com.my/batch.accountupdates/${project.version}/cfg/configuration
>> <http://com.my/batch.accountupdates/$%7Bproject.version%7D/cfg/configuration>
>> </configfile>
>> <feature>camel-core</feature>
>> <feature>camel-blueprint</feature>
>> snip
>>
>> And some route like:
>>
>> <to
>> uri="{{batch.local.outbox}}?fileExist=Append&fileName=${header.outFile}"
>> />
>>
>> On Fri, Jul 8, 2016 at 8:33 AM, Christian Schneider <
>> chris@die-schneider.net> wrote:
>>
>>> Can you give some examples of typical config properties that need to be
>>> shared between these bundles. Maybe they lead to an idea for a different
>>> design.
>>>
>>> Christian
>>>
>>> On 08.07.2016 15:09, Brad Johnson wrote:
>>>
>>>> Christian,
>>>>
>>>> Thanks for the feedback. I'm actually looking for a bit more robust
>>>> solution. Just the one small project I'm working on now has 12 business
>>>> processes with a number of OSGi services that provide cross-cutting
>>>> concerns. In this case they are service like credit card authorization,
>>>> refunds, etc. CXF front ends them with REST/SOAP and I use recipientList
>>>> to route them. But each of those business processes use OSGi services that
>>>> might call out to banks, PayPal, analytics services, etc. Keeping these
>>>> nicely segregated in their own bundles makes them very testable for the
>>>> routing, data transformation to/from canonical form, etc. But
>>>> configuration management is a bit of a pain because of the PID pinning. I
>>>> use update strategy reload on the bundles so that configurations can be
>>>> changed in different environments.
>>>>
>>>> Until now I've kept my configuration files in each bundle and pop them
>>>> out using the features install mechanism. But I'm rethinking that based on
>>>> these discussions. I don't know if the Maven properties plugin would do
>>>> what I'm thinking about but it might be a platform to develop such a
>>>> plugin. In this case I'd have a separate configuration bundle with my PID
>>>> cfgs in them and N levels of parent cfg files. The properties would just
>>>> be rolled up and written out into PID specific cfg files. If I define a
>>>> port or directory in a parent then all the children would inherit or
>>>> override that property. That would permit the use of profiles for dev,
>>>> test and production as well. Modifying any of the cfg files and then
>>>> putting that through Jenkins would result in a nice configuration bundle
>>>> that once reinstalled would trigger a reload. In the end the port or
>>>> directory or endpoint configuration information would be duplicated in each
>>>> cfg but it wouldn't require hand massaging of each cfg to change.
>>>>
>>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
After a bit of experimentation yesterday it appears that the properties
Maven plugin along with filtered resources with .cfg files will work
admirably for this purpose. Multiple properties files can be load one
after the other permitting overwriting and the properties substitutions in
the .cfg files works like a champ.
I'll be working with it more today but this is going to solve that rather
sticky problem for me.
Brad
On Fri, Jul 8, 2016 at 4:11 PM, Brad Johnson <br...@mediadriver.com>
wrote:
> David,
>
> Multilocations would be marvelous but it doesn't appear that there is any
> focus on blueprint right now. For my clients it wouldn't help anyway
> because Fuse is Karaf 2.x and on OSGi R4. That's an entirely different
> issue that I'm extremely unhappy about but can't change. Red Hat is in the
> driver's seat there. If I had my way I'd prefer multiple small
> installations of Karaf 4 with my own custom distributions. Such is life.
>
> The Configurator might work as well. I'm obviously hamstrung currently by
> the platform. So when I look at solutions that require specification
> changes or changes to focus on project priorities across OSGi where I don't
> have any inlets, Aries and Camel there isn't much I can expect
> realistically.
>
> You probably read Christian's comments about Camel and DS with the SCR.
> My experience trying to use the two together was pretty dreadful. I'll
> attempt it again in the future I'm sure as I always prototype stuff on a
> regular basis. Being in CXF, JMS and Camel means that adopting DS is likely
> just going to buy me more headaches because I don't see any way out of
> Blueprint right now even if I decided to once again delve into Camel's Java
> DSL.
>
> Modifying Maven builds or even creating a custom plugin is something I can
> do. With filtered resources I can profiles I can create dev, test, prod
> cfg files and compile those into a single bundle (probably with my
> features) and then have goals that install the relevant cfgs depending on
> the feature installed.
>
> Hacking together something like that doesn't make me happy and I would
> prefer a more elegant solution. But having read the Camel mailing list
> long enough I know I'm not the only one who wrestles with that problem in
> Blueprint with the pinned PIDs. At least a compilation mechanism via Maven
> would permit me to work with single PIDs but not duplicate data in multiple
> files. It would also have a side benefit of making it more natural to
> modify the applicable cfg in the configuration bundle and use that to
> install the configurations in a controlled manner rather than modifying
> already installed cfg files in the etc directory.
>
> Most of that I can probably do myself out of the box with standard Maven
> plugins. The only one that will probably require custom code is something
> to roll up cfg properties before writing out to the pid.cfg.
>
>
>
>
> On Fri, Jul 8, 2016 at 9:52 AM, Brad Johnson <brad.johnson@mediadriver.com
> > wrote:
>
>> I don't think anyone missed your points.
>>
>> On Fri, Jul 8, 2016 at 9:45 AM, David Jencks <da...@yahoo.com>
>> wrote:
>>
>>> Somehow my original points have, I think, gotten completely lost.
>>>
>>> 1. Multilocations should completely solve the original problem of
>>> sharing a configuration across bundles. This requires an R5 + config
>>> admin, which has been around for years. I don’t think reinventing this
>>> wheel is plausible.
>>> 2. Blueprint should work with multi locations out of the box with no
>>> problems. If not, it’s almost certainly an easy to fix bug. Try it, lets
>>> find out.
>>>
>>>
>>> ————
>>>
>>> 3. The additional idea of combining configurations with overrides is
>>> very similar to the DS multiple pid support. Adding that to blueprint
>>> might be a big job, and IMO ought to proceed as part of specifying
>>> blueprint CM support (at all), but is presumably doable.
>>> 4. Alternatively, the particular form of combining configuration data
>>> shown, apparently based on matching patterns in input data file names,
>>> could be done by a management agent that creates the configurations in the
>>> first place, e.g. a modified fileinstall (I don’t know if this is what
>>> karaf uses). There’s the Configurer work DavidB mentions that might also
>>> be relevant.
>>>
>>> ——————
>>>
>>> 5. I think it’s odd that if blueprint is so great and so popular the
>>> spec work on it hasn’t progressed. It seems to me like using CMP entity
>>> beans in an ejb 3 application. Maybe everyone is happy developing the
>>> single implementation without a spec, but it seems to me like the people
>>> using blueprint aren’t aware of new features in other osgi specs they might
>>> like to emulate, such as the multiple pid support. This just seems odd to
>>> me.
>>>
>>> —————————
>>> While a voting, company, membership in OSGI is IIUC somewhat expensive,
>>> you can become an OSGI supporter and participate (non-voting) in spec
>>> development for free: https://www.osgi.org/join/membership-benefits/
>>> (see the bottom)
>>>
>>> thanks
>>> david jencks
>>>
>>> On Jul 8, 2016, at 7:22 AM, Brad Johnson <br...@mediadriver.com>
>>> wrote:
>>>
>>> After getting into these discussions I started thinking that perhaps I'd
>>> move all the configuration files into one bundle and install them from
>>> features file that way. I could have dev/test/prod cfg files in that same
>>> bundle.
>>>
>>> Using a combination of filtered resources and some other mechanics then
>>> I can perhaps come up with a way so that
>>>
>>> com.my.batch.transaction.cfg
>>> com.my.batch.accountupdates.cfg
>>>
>>> have a com.my.batch.parent.cfg and during Maven build it is read into
>>> and made part of both the transaction and account updates.cfg files. Those
>>> are then put into the configuration bundle. When that configuration bundle
>>> is installed the PIDs/properties match the bundles looking for them but
>>> contain the common information as already been flattened into them.
>>>
>>> That configuration bundle could also have test/dev/production cfg files
>>> and the features file could permit installing test, dev or production the
>>> only difference being which set of configuration files they installed
>>> before installing the bundles themselves.
>>>
>>>
>>> On Fri, Jul 8, 2016 at 9:12 AM, Brad Johnson <
>>> brad.johnson@mediadriver.com> wrote:
>>>
>>>> Here's a small example. The two batch processes do very different
>>>> things yet share some common configuration information pertaining to
>>>> directories, ftp and service endpoints. That configuration information
>>>> obviously also varies between dev, test, and production. This is one small
>>>> part of the project. The connector project is already a crosscutting
>>>> concern that keeps its connection information separated from all the other
>>>> business processes/services that use it. Some of the properties have queue
>>>> names (SEDA or JMS) that are shared between bundles and use runtime
>>>> substitution in Camel. But duplicating configuration information between
>>>> the bundles and hand massaging it is error prone and makes refactoring a
>>>> pain.
>>>>
>>>> <feature name="someproject" version="${project.version}">
>>>>
>>>> <configfile finalname="/etc/com.litle.cfg"
>>>> override="false">mvn:com.my.connectors/litle/${project.version}/cfg/configuration</configfile>
>>>> <configfile finalname="/etc/com.my.batch.transactions.cfg"
>>>> override="false">mvn:
>>>> com.my/batch.transactions/${project.version}/cfg/configuration
>>>> <http://com.my/batch.transactions/$%7Bproject.version%7D/cfg/configuration>
>>>> </configfile>
>>>> <configfile finalname="/etc/com.my.batch.accountupdates.cfg"
>>>> override="false">mvn:
>>>> com.my/batch.accountupdates/${project.version}/cfg/configuration
>>>> <http://com.my/batch.accountupdates/$%7Bproject.version%7D/cfg/configuration>
>>>> </configfile>
>>>> <feature>camel-core</feature>
>>>> <feature>camel-blueprint</feature>
>>>> snip
>>>>
>>>> And some route like:
>>>>
>>>> <to
>>>> uri="{{batch.local.outbox}}?fileExist=Append&fileName=${header.outFile}"
>>>> />
>>>>
>>>> On Fri, Jul 8, 2016 at 8:33 AM, Christian Schneider <
>>>> chris@die-schneider.net> wrote:
>>>>
>>>>> Can you give some examples of typical config properties that need to
>>>>> be shared between these bundles. Maybe they lead to an idea for a different
>>>>> design.
>>>>>
>>>>> Christian
>>>>>
>>>>> On 08.07.2016 15:09, Brad Johnson wrote:
>>>>>
>>>>>> Christian,
>>>>>>
>>>>>> Thanks for the feedback. I'm actually looking for a bit more robust
>>>>>> solution. Just the one small project I'm working on now has 12 business
>>>>>> processes with a number of OSGi services that provide cross-cutting
>>>>>> concerns. In this case they are service like credit card authorization,
>>>>>> refunds, etc. CXF front ends them with REST/SOAP and I use recipientList
>>>>>> to route them. But each of those business processes use OSGi services that
>>>>>> might call out to banks, PayPal, analytics services, etc. Keeping these
>>>>>> nicely segregated in their own bundles makes them very testable for the
>>>>>> routing, data transformation to/from canonical form, etc. But
>>>>>> configuration management is a bit of a pain because of the PID pinning. I
>>>>>> use update strategy reload on the bundles so that configurations can be
>>>>>> changed in different environments.
>>>>>>
>>>>>> Until now I've kept my configuration files in each bundle and pop
>>>>>> them out using the features install mechanism. But I'm rethinking that
>>>>>> based on these discussions. I don't know if the Maven properties plugin
>>>>>> would do what I'm thinking about but it might be a platform to develop such
>>>>>> a plugin. In this case I'd have a separate configuration bundle with my
>>>>>> PID cfgs in them and N levels of parent cfg files. The properties would
>>>>>> just be rolled up and written out into PID specific cfg files. If I define
>>>>>> a port or directory in a parent then all the children would inherit or
>>>>>> override that property. That would permit the use of profiles for dev,
>>>>>> test and production as well. Modifying any of the cfg files and then
>>>>>> putting that through Jenkins would result in a nice configuration bundle
>>>>>> that once reinstalled would trigger a reload. In the end the port or
>>>>>> directory or endpoint configuration information would be duplicated in each
>>>>>> cfg but it wouldn't require hand massaging of each cfg to change.
>>>>>>
>>>>>>
>>>>> --
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>>
>>>>> Open Source Architect
>>>>> http://www.talend.com
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
David,
Multilocations would be marvelous but it doesn't appear that there is any
focus on blueprint right now. For my clients it wouldn't help anyway
because Fuse is Karaf 2.x and on OSGi R4. That's an entirely different
issue that I'm extremely unhappy about but can't change. Red Hat is in the
driver's seat there. If I had my way I'd prefer multiple small
installations of Karaf 4 with my own custom distributions. Such is life.
The Configurator might work as well. I'm obviously hamstrung currently by
the platform. So when I look at solutions that require specification
changes or changes to focus on project priorities across OSGi where I don't
have any inlets, Aries and Camel there isn't much I can expect
realistically.
You probably read Christian's comments about Camel and DS with the SCR. My
experience trying to use the two together was pretty dreadful. I'll
attempt it again in the future I'm sure as I always prototype stuff on a
regular basis. Being in CXF, JMS and Camel means that adopting DS is likely
just going to buy me more headaches because I don't see any way out of
Blueprint right now even if I decided to once again delve into Camel's Java
DSL.
Modifying Maven builds or even creating a custom plugin is something I can
do. With filtered resources I can profiles I can create dev, test, prod
cfg files and compile those into a single bundle (probably with my
features) and then have goals that install the relevant cfgs depending on
the feature installed.
Hacking together something like that doesn't make me happy and I would
prefer a more elegant solution. But having read the Camel mailing list
long enough I know I'm not the only one who wrestles with that problem in
Blueprint with the pinned PIDs. At least a compilation mechanism via Maven
would permit me to work with single PIDs but not duplicate data in multiple
files. It would also have a side benefit of making it more natural to
modify the applicable cfg in the configuration bundle and use that to
install the configurations in a controlled manner rather than modifying
already installed cfg files in the etc directory.
Most of that I can probably do myself out of the box with standard Maven
plugins. The only one that will probably require custom code is something
to roll up cfg properties before writing out to the pid.cfg.
On Fri, Jul 8, 2016 at 9:52 AM, Brad Johnson <br...@mediadriver.com>
wrote:
> I don't think anyone missed your points.
>
> On Fri, Jul 8, 2016 at 9:45 AM, David Jencks <da...@yahoo.com>
> wrote:
>
>> Somehow my original points have, I think, gotten completely lost.
>>
>> 1. Multilocations should completely solve the original problem of sharing
>> a configuration across bundles. This requires an R5 + config admin, which
>> has been around for years. I don’t think reinventing this wheel is
>> plausible.
>> 2. Blueprint should work with multi locations out of the box with no
>> problems. If not, it’s almost certainly an easy to fix bug. Try it, lets
>> find out.
>>
>>
>> ————
>>
>> 3. The additional idea of combining configurations with overrides is very
>> similar to the DS multiple pid support. Adding that to blueprint might be
>> a big job, and IMO ought to proceed as part of specifying blueprint CM
>> support (at all), but is presumably doable.
>> 4. Alternatively, the particular form of combining configuration data
>> shown, apparently based on matching patterns in input data file names,
>> could be done by a management agent that creates the configurations in the
>> first place, e.g. a modified fileinstall (I don’t know if this is what
>> karaf uses). There’s the Configurer work DavidB mentions that might also
>> be relevant.
>>
>> ——————
>>
>> 5. I think it’s odd that if blueprint is so great and so popular the spec
>> work on it hasn’t progressed. It seems to me like using CMP entity beans
>> in an ejb 3 application. Maybe everyone is happy developing the single
>> implementation without a spec, but it seems to me like the people using
>> blueprint aren’t aware of new features in other osgi specs they might like
>> to emulate, such as the multiple pid support. This just seems odd to me.
>>
>> —————————
>> While a voting, company, membership in OSGI is IIUC somewhat expensive,
>> you can become an OSGI supporter and participate (non-voting) in spec
>> development for free: https://www.osgi.org/join/membership-benefits/
>> (see the bottom)
>>
>> thanks
>> david jencks
>>
>> On Jul 8, 2016, at 7:22 AM, Brad Johnson <br...@mediadriver.com>
>> wrote:
>>
>> After getting into these discussions I started thinking that perhaps I'd
>> move all the configuration files into one bundle and install them from
>> features file that way. I could have dev/test/prod cfg files in that same
>> bundle.
>>
>> Using a combination of filtered resources and some other mechanics then I
>> can perhaps come up with a way so that
>>
>> com.my.batch.transaction.cfg
>> com.my.batch.accountupdates.cfg
>>
>> have a com.my.batch.parent.cfg and during Maven build it is read into and
>> made part of both the transaction and account updates.cfg files. Those are
>> then put into the configuration bundle. When that configuration bundle is
>> installed the PIDs/properties match the bundles looking for them but
>> contain the common information as already been flattened into them.
>>
>> That configuration bundle could also have test/dev/production cfg files
>> and the features file could permit installing test, dev or production the
>> only difference being which set of configuration files they installed
>> before installing the bundles themselves.
>>
>>
>> On Fri, Jul 8, 2016 at 9:12 AM, Brad Johnson <
>> brad.johnson@mediadriver.com> wrote:
>>
>>> Here's a small example. The two batch processes do very different
>>> things yet share some common configuration information pertaining to
>>> directories, ftp and service endpoints. That configuration information
>>> obviously also varies between dev, test, and production. This is one small
>>> part of the project. The connector project is already a crosscutting
>>> concern that keeps its connection information separated from all the other
>>> business processes/services that use it. Some of the properties have queue
>>> names (SEDA or JMS) that are shared between bundles and use runtime
>>> substitution in Camel. But duplicating configuration information between
>>> the bundles and hand massaging it is error prone and makes refactoring a
>>> pain.
>>>
>>> <feature name="someproject" version="${project.version}">
>>>
>>> <configfile finalname="/etc/com.litle.cfg"
>>> override="false">mvn:com.my.connectors/litle/${project.version}/cfg/configuration</configfile>
>>> <configfile finalname="/etc/com.my.batch.transactions.cfg"
>>> override="false">mvn:
>>> com.my/batch.transactions/${project.version}/cfg/configuration
>>> <http://com.my/batch.transactions/$%7Bproject.version%7D/cfg/configuration>
>>> </configfile>
>>> <configfile finalname="/etc/com.my.batch.accountupdates.cfg"
>>> override="false">mvn:
>>> com.my/batch.accountupdates/${project.version}/cfg/configuration
>>> <http://com.my/batch.accountupdates/$%7Bproject.version%7D/cfg/configuration>
>>> </configfile>
>>> <feature>camel-core</feature>
>>> <feature>camel-blueprint</feature>
>>> snip
>>>
>>> And some route like:
>>>
>>> <to
>>> uri="{{batch.local.outbox}}?fileExist=Append&fileName=${header.outFile}"
>>> />
>>>
>>> On Fri, Jul 8, 2016 at 8:33 AM, Christian Schneider <
>>> chris@die-schneider.net> wrote:
>>>
>>>> Can you give some examples of typical config properties that need to be
>>>> shared between these bundles. Maybe they lead to an idea for a different
>>>> design.
>>>>
>>>> Christian
>>>>
>>>> On 08.07.2016 15:09, Brad Johnson wrote:
>>>>
>>>>> Christian,
>>>>>
>>>>> Thanks for the feedback. I'm actually looking for a bit more robust
>>>>> solution. Just the one small project I'm working on now has 12 business
>>>>> processes with a number of OSGi services that provide cross-cutting
>>>>> concerns. In this case they are service like credit card authorization,
>>>>> refunds, etc. CXF front ends them with REST/SOAP and I use recipientList
>>>>> to route them. But each of those business processes use OSGi services that
>>>>> might call out to banks, PayPal, analytics services, etc. Keeping these
>>>>> nicely segregated in their own bundles makes them very testable for the
>>>>> routing, data transformation to/from canonical form, etc. But
>>>>> configuration management is a bit of a pain because of the PID pinning. I
>>>>> use update strategy reload on the bundles so that configurations can be
>>>>> changed in different environments.
>>>>>
>>>>> Until now I've kept my configuration files in each bundle and pop them
>>>>> out using the features install mechanism. But I'm rethinking that based on
>>>>> these discussions. I don't know if the Maven properties plugin would do
>>>>> what I'm thinking about but it might be a platform to develop such a
>>>>> plugin. In this case I'd have a separate configuration bundle with my PID
>>>>> cfgs in them and N levels of parent cfg files. The properties would just
>>>>> be rolled up and written out into PID specific cfg files. If I define a
>>>>> port or directory in a parent then all the children would inherit or
>>>>> override that property. That would permit the use of profiles for dev,
>>>>> test and production as well. Modifying any of the cfg files and then
>>>>> putting that through Jenkins would result in a nice configuration bundle
>>>>> that once reinstalled would trigger a reload. In the end the port or
>>>>> directory or endpoint configuration information would be duplicated in each
>>>>> cfg but it wouldn't require hand massaging of each cfg to change.
>>>>>
>>>>>
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> http://www.talend.com
>>>>
>>>>
>>>
>>
>>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
I don't think anyone missed your points.
On Fri, Jul 8, 2016 at 9:45 AM, David Jencks <da...@yahoo.com> wrote:
> Somehow my original points have, I think, gotten completely lost.
>
> 1. Multilocations should completely solve the original problem of sharing
> a configuration across bundles. This requires an R5 + config admin, which
> has been around for years. I don’t think reinventing this wheel is
> plausible.
> 2. Blueprint should work with multi locations out of the box with no
> problems. If not, it’s almost certainly an easy to fix bug. Try it, lets
> find out.
>
>
> ————
>
> 3. The additional idea of combining configurations with overrides is very
> similar to the DS multiple pid support. Adding that to blueprint might be
> a big job, and IMO ought to proceed as part of specifying blueprint CM
> support (at all), but is presumably doable.
> 4. Alternatively, the particular form of combining configuration data
> shown, apparently based on matching patterns in input data file names,
> could be done by a management agent that creates the configurations in the
> first place, e.g. a modified fileinstall (I don’t know if this is what
> karaf uses). There’s the Configurer work DavidB mentions that might also
> be relevant.
>
> ——————
>
> 5. I think it’s odd that if blueprint is so great and so popular the spec
> work on it hasn’t progressed. It seems to me like using CMP entity beans
> in an ejb 3 application. Maybe everyone is happy developing the single
> implementation without a spec, but it seems to me like the people using
> blueprint aren’t aware of new features in other osgi specs they might like
> to emulate, such as the multiple pid support. This just seems odd to me.
>
> —————————
> While a voting, company, membership in OSGI is IIUC somewhat expensive,
> you can become an OSGI supporter and participate (non-voting) in spec
> development for free: https://www.osgi.org/join/membership-benefits/ (see
> the bottom)
>
> thanks
> david jencks
>
> On Jul 8, 2016, at 7:22 AM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
> After getting into these discussions I started thinking that perhaps I'd
> move all the configuration files into one bundle and install them from
> features file that way. I could have dev/test/prod cfg files in that same
> bundle.
>
> Using a combination of filtered resources and some other mechanics then I
> can perhaps come up with a way so that
>
> com.my.batch.transaction.cfg
> com.my.batch.accountupdates.cfg
>
> have a com.my.batch.parent.cfg and during Maven build it is read into and
> made part of both the transaction and account updates.cfg files. Those are
> then put into the configuration bundle. When that configuration bundle is
> installed the PIDs/properties match the bundles looking for them but
> contain the common information as already been flattened into them.
>
> That configuration bundle could also have test/dev/production cfg files
> and the features file could permit installing test, dev or production the
> only difference being which set of configuration files they installed
> before installing the bundles themselves.
>
>
> On Fri, Jul 8, 2016 at 9:12 AM, Brad Johnson <brad.johnson@mediadriver.com
> > wrote:
>
>> Here's a small example. The two batch processes do very different things
>> yet share some common configuration information pertaining to directories,
>> ftp and service endpoints. That configuration information obviously also
>> varies between dev, test, and production. This is one small part of the
>> project. The connector project is already a crosscutting concern that
>> keeps its connection information separated from all the other business
>> processes/services that use it. Some of the properties have queue names
>> (SEDA or JMS) that are shared between bundles and use runtime substitution
>> in Camel. But duplicating configuration information between the bundles
>> and hand massaging it is error prone and makes refactoring a pain.
>>
>> <feature name="someproject" version="${project.version}">
>>
>> <configfile finalname="/etc/com.litle.cfg"
>> override="false">mvn:com.my.connectors/litle/${project.version}/cfg/configuration</configfile>
>> <configfile finalname="/etc/com.my.batch.transactions.cfg"
>> override="false">mvn:
>> com.my/batch.transactions/${project.version}/cfg/configuration
>> <http://com.my/batch.transactions/$%7Bproject.version%7D/cfg/configuration>
>> </configfile>
>> <configfile finalname="/etc/com.my.batch.accountupdates.cfg"
>> override="false">mvn:
>> com.my/batch.accountupdates/${project.version}/cfg/configuration
>> <http://com.my/batch.accountupdates/$%7Bproject.version%7D/cfg/configuration>
>> </configfile>
>> <feature>camel-core</feature>
>> <feature>camel-blueprint</feature>
>> snip
>>
>> And some route like:
>>
>> <to
>> uri="{{batch.local.outbox}}?fileExist=Append&fileName=${header.outFile}"
>> />
>>
>> On Fri, Jul 8, 2016 at 8:33 AM, Christian Schneider <
>> chris@die-schneider.net> wrote:
>>
>>> Can you give some examples of typical config properties that need to be
>>> shared between these bundles. Maybe they lead to an idea for a different
>>> design.
>>>
>>> Christian
>>>
>>> On 08.07.2016 15:09, Brad Johnson wrote:
>>>
>>>> Christian,
>>>>
>>>> Thanks for the feedback. I'm actually looking for a bit more robust
>>>> solution. Just the one small project I'm working on now has 12 business
>>>> processes with a number of OSGi services that provide cross-cutting
>>>> concerns. In this case they are service like credit card authorization,
>>>> refunds, etc. CXF front ends them with REST/SOAP and I use recipientList
>>>> to route them. But each of those business processes use OSGi services that
>>>> might call out to banks, PayPal, analytics services, etc. Keeping these
>>>> nicely segregated in their own bundles makes them very testable for the
>>>> routing, data transformation to/from canonical form, etc. But
>>>> configuration management is a bit of a pain because of the PID pinning. I
>>>> use update strategy reload on the bundles so that configurations can be
>>>> changed in different environments.
>>>>
>>>> Until now I've kept my configuration files in each bundle and pop them
>>>> out using the features install mechanism. But I'm rethinking that based on
>>>> these discussions. I don't know if the Maven properties plugin would do
>>>> what I'm thinking about but it might be a platform to develop such a
>>>> plugin. In this case I'd have a separate configuration bundle with my PID
>>>> cfgs in them and N levels of parent cfg files. The properties would just
>>>> be rolled up and written out into PID specific cfg files. If I define a
>>>> port or directory in a parent then all the children would inherit or
>>>> override that property. That would permit the use of profiles for dev,
>>>> test and production as well. Modifying any of the cfg files and then
>>>> putting that through Jenkins would result in a nice configuration bundle
>>>> that once reinstalled would trigger a reload. In the end the port or
>>>> directory or endpoint configuration information would be duplicated in each
>>>> cfg but it wouldn't require hand massaging of each cfg to change.
>>>>
>>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>>
>
>
Re: Properties cfg wish...
Posted by David Jencks <da...@yahoo.com>.
Somehow my original points have, I think, gotten completely lost.
1. Multilocations should completely solve the original problem of sharing a configuration across bundles. This requires an R5 + config admin, which has been around for years. I don’t think reinventing this wheel is plausible.
2. Blueprint should work with multi locations out of the box with no problems. If not, it’s almost certainly an easy to fix bug. Try it, lets find out.
————
3. The additional idea of combining configurations with overrides is very similar to the DS multiple pid support. Adding that to blueprint might be a big job, and IMO ought to proceed as part of specifying blueprint CM support (at all), but is presumably doable.
4. Alternatively, the particular form of combining configuration data shown, apparently based on matching patterns in input data file names, could be done by a management agent that creates the configurations in the first place, e.g. a modified fileinstall (I don’t know if this is what karaf uses). There’s the Configurer work DavidB mentions that might also be relevant.
——————
5. I think it’s odd that if blueprint is so great and so popular the spec work on it hasn’t progressed. It seems to me like using CMP entity beans in an ejb 3 application. Maybe everyone is happy developing the single implementation without a spec, but it seems to me like the people using blueprint aren’t aware of new features in other osgi specs they might like to emulate, such as the multiple pid support. This just seems odd to me.
—————————
While a voting, company, membership in OSGI is IIUC somewhat expensive, you can become an OSGI supporter and participate (non-voting) in spec development for free: https://www.osgi.org/join/membership-benefits/ (see the bottom)
thanks
david jencks
> On Jul 8, 2016, at 7:22 AM, Brad Johnson <br...@mediadriver.com> wrote:
>
> After getting into these discussions I started thinking that perhaps I'd move all the configuration files into one bundle and install them from features file that way. I could have dev/test/prod cfg files in that same bundle.
>
> Using a combination of filtered resources and some other mechanics then I can perhaps come up with a way so that
>
> com.my.batch.transaction.cfg
> com.my.batch.accountupdates.cfg
>
> have a com.my.batch.parent.cfg and during Maven build it is read into and made part of both the transaction and account updates.cfg files. Those are then put into the configuration bundle. When that configuration bundle is installed the PIDs/properties match the bundles looking for them but contain the common information as already been flattened into them.
>
> That configuration bundle could also have test/dev/production cfg files and the features file could permit installing test, dev or production the only difference being which set of configuration files they installed before installing the bundles themselves.
>
>
> On Fri, Jul 8, 2016 at 9:12 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
> Here's a small example. The two batch processes do very different things yet share some common configuration information pertaining to directories, ftp and service endpoints. That configuration information obviously also varies between dev, test, and production. This is one small part of the project. The connector project is already a crosscutting concern that keeps its connection information separated from all the other business processes/services that use it. Some of the properties have queue names (SEDA or JMS) that are shared between bundles and use runtime substitution in Camel. But duplicating configuration information between the bundles and hand massaging it is error prone and makes refactoring a pain.
>
> <feature name="someproject" version="${project.version}">
>
> <configfile finalname="/etc/com.litle.cfg" override="false">mvn:com.my.connectors/litle/${project.version}/cfg/configuration</configfile>
> <configfile finalname="/etc/com.my.batch.transactions.cfg" override="false">mvn:com.my/batch.transactions/${project.version}/cfg/configuration <http://com.my/batch.transactions/$%7Bproject.version%7D/cfg/configuration></configfile>
> <configfile finalname="/etc/com.my.batch.accountupdates.cfg" override="false">mvn:com.my/batch.accountupdates/${project.version}/cfg/configuration <http://com.my/batch.accountupdates/$%7Bproject.version%7D/cfg/configuration></configfile>
>
> <feature>camel-core</feature>
> <feature>camel-blueprint</feature>
> snip
>
> And some route like:
>
> <to uri="{{batch.local.outbox}}?fileExist=Append&fileName=${header.outFile}" />
>
> On Fri, Jul 8, 2016 at 8:33 AM, Christian Schneider <chris@die-schneider.net <ma...@die-schneider.net>> wrote:
> Can you give some examples of typical config properties that need to be shared between these bundles. Maybe they lead to an idea for a different design.
>
> Christian
>
> On 08.07.2016 15:09, Brad Johnson wrote:
> Christian,
>
> Thanks for the feedback. I'm actually looking for a bit more robust solution. Just the one small project I'm working on now has 12 business processes with a number of OSGi services that provide cross-cutting concerns. In this case they are service like credit card authorization, refunds, etc. CXF front ends them with REST/SOAP and I use recipientList to route them. But each of those business processes use OSGi services that might call out to banks, PayPal, analytics services, etc. Keeping these nicely segregated in their own bundles makes them very testable for the routing, data transformation to/from canonical form, etc. But configuration management is a bit of a pain because of the PID pinning. I use update strategy reload on the bundles so that configurations can be changed in different environments.
>
> Until now I've kept my configuration files in each bundle and pop them out using the features install mechanism. But I'm rethinking that based on these discussions. I don't know if the Maven properties plugin would do what I'm thinking about but it might be a platform to develop such a plugin. In this case I'd have a separate configuration bundle with my PID cfgs in them and N levels of parent cfg files. The properties would just be rolled up and written out into PID specific cfg files. If I define a port or directory in a parent then all the children would inherit or override that property. That would permit the use of profiles for dev, test and production as well. Modifying any of the cfg files and then putting that through Jenkins would result in a nice configuration bundle that once reinstalled would trigger a reload. In the end the port or directory or endpoint configuration information would be duplicated in each cfg but it wouldn't require hand massaging of each cfg to change.
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>
> Open Source Architect
> http://www.talend.com <http://www.talend.com/>
>
>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
After getting into these discussions I started thinking that perhaps I'd
move all the configuration files into one bundle and install them from
features file that way. I could have dev/test/prod cfg files in that same
bundle.
Using a combination of filtered resources and some other mechanics then I
can perhaps come up with a way so that
com.my.batch.transaction.cfg
com.my.batch.accountupdates.cfg
have a com.my.batch.parent.cfg and during Maven build it is read into and
made part of both the transaction and account updates.cfg files. Those are
then put into the configuration bundle. When that configuration bundle is
installed the PIDs/properties match the bundles looking for them but
contain the common information as already been flattened into them.
That configuration bundle could also have test/dev/production cfg files and
the features file could permit installing test, dev or production the only
difference being which set of configuration files they installed before
installing the bundles themselves.
On Fri, Jul 8, 2016 at 9:12 AM, Brad Johnson <br...@mediadriver.com>
wrote:
> Here's a small example. The two batch processes do very different things
> yet share some common configuration information pertaining to directories,
> ftp and service endpoints. That configuration information obviously also
> varies between dev, test, and production. This is one small part of the
> project. The connector project is already a crosscutting concern that
> keeps its connection information separated from all the other business
> processes/services that use it. Some of the properties have queue names
> (SEDA or JMS) that are shared between bundles and use runtime substitution
> in Camel. But duplicating configuration information between the bundles
> and hand massaging it is error prone and makes refactoring a pain.
>
> <feature name="someproject" version="${project.version}">
>
> <configfile finalname="/etc/com.litle.cfg"
> override="false">mvn:com.my.connectors/litle/${project.version}/cfg/configuration</configfile>
> <configfile finalname="/etc/com.my.batch.transactions.cfg"
> override="false">mvn:
> com.my/batch.transactions/${project.version}/cfg/configuration
> <http://com.my/batch.transactions/$%7Bproject.version%7D/cfg/configuration>
> </configfile>
> <configfile finalname="/etc/com.my.batch.accountupdates.cfg"
> override="false">mvn:
> com.my/batch.accountupdates/${project.version}/cfg/configuration
> <http://com.my/batch.accountupdates/$%7Bproject.version%7D/cfg/configuration>
> </configfile>
> <feature>camel-core</feature>
> <feature>camel-blueprint</feature>
> snip
>
> And some route like:
>
> <to
> uri="{{batch.local.outbox}}?fileExist=Append&fileName=${header.outFile}"
> />
>
> On Fri, Jul 8, 2016 at 8:33 AM, Christian Schneider <
> chris@die-schneider.net> wrote:
>
>> Can you give some examples of typical config properties that need to be
>> shared between these bundles. Maybe they lead to an idea for a different
>> design.
>>
>> Christian
>>
>> On 08.07.2016 15:09, Brad Johnson wrote:
>>
>>> Christian,
>>>
>>> Thanks for the feedback. I'm actually looking for a bit more robust
>>> solution. Just the one small project I'm working on now has 12 business
>>> processes with a number of OSGi services that provide cross-cutting
>>> concerns. In this case they are service like credit card authorization,
>>> refunds, etc. CXF front ends them with REST/SOAP and I use recipientList
>>> to route them. But each of those business processes use OSGi services that
>>> might call out to banks, PayPal, analytics services, etc. Keeping these
>>> nicely segregated in their own bundles makes them very testable for the
>>> routing, data transformation to/from canonical form, etc. But
>>> configuration management is a bit of a pain because of the PID pinning. I
>>> use update strategy reload on the bundles so that configurations can be
>>> changed in different environments.
>>>
>>> Until now I've kept my configuration files in each bundle and pop them
>>> out using the features install mechanism. But I'm rethinking that based on
>>> these discussions. I don't know if the Maven properties plugin would do
>>> what I'm thinking about but it might be a platform to develop such a
>>> plugin. In this case I'd have a separate configuration bundle with my PID
>>> cfgs in them and N levels of parent cfg files. The properties would just
>>> be rolled up and written out into PID specific cfg files. If I define a
>>> port or directory in a parent then all the children would inherit or
>>> override that property. That would permit the use of profiles for dev,
>>> test and production as well. Modifying any of the cfg files and then
>>> putting that through Jenkins would result in a nice configuration bundle
>>> that once reinstalled would trigger a reload. In the end the port or
>>> directory or endpoint configuration information would be duplicated in each
>>> cfg but it wouldn't require hand massaging of each cfg to change.
>>>
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
Here's a small example. The two batch processes do very different things
yet share some common configuration information pertaining to directories,
ftp and service endpoints. That configuration information obviously also
varies between dev, test, and production. This is one small part of the
project. The connector project is already a crosscutting concern that
keeps its connection information separated from all the other business
processes/services that use it. Some of the properties have queue names
(SEDA or JMS) that are shared between bundles and use runtime substitution
in Camel. But duplicating configuration information between the bundles
and hand massaging it is error prone and makes refactoring a pain.
<feature name="someproject" version="${project.version}">
<configfile finalname="/etc/com.litle.cfg"
override="false">mvn:com.my.connectors/litle/${project.version}/cfg/configuration</configfile>
<configfile finalname="/etc/com.my.batch.transactions.cfg"
override="false">mvn:
com.my/batch.transactions/${project.version}/cfg/configuration</configfile>
<configfile finalname="/etc/com.my.batch.accountupdates.cfg"
override="false">mvn:
com.my/batch.accountupdates/${project.version}/cfg/configuration
</configfile>
<feature>camel-core</feature>
<feature>camel-blueprint</feature>
snip
And some route like:
<to
uri="{{batch.local.outbox}}?fileExist=Append&fileName=${header.outFile}"
/>
On Fri, Jul 8, 2016 at 8:33 AM, Christian Schneider <chris@die-schneider.net
> wrote:
> Can you give some examples of typical config properties that need to be
> shared between these bundles. Maybe they lead to an idea for a different
> design.
>
> Christian
>
> On 08.07.2016 15:09, Brad Johnson wrote:
>
>> Christian,
>>
>> Thanks for the feedback. I'm actually looking for a bit more robust
>> solution. Just the one small project I'm working on now has 12 business
>> processes with a number of OSGi services that provide cross-cutting
>> concerns. In this case they are service like credit card authorization,
>> refunds, etc. CXF front ends them with REST/SOAP and I use recipientList
>> to route them. But each of those business processes use OSGi services that
>> might call out to banks, PayPal, analytics services, etc. Keeping these
>> nicely segregated in their own bundles makes them very testable for the
>> routing, data transformation to/from canonical form, etc. But
>> configuration management is a bit of a pain because of the PID pinning. I
>> use update strategy reload on the bundles so that configurations can be
>> changed in different environments.
>>
>> Until now I've kept my configuration files in each bundle and pop them
>> out using the features install mechanism. But I'm rethinking that based on
>> these discussions. I don't know if the Maven properties plugin would do
>> what I'm thinking about but it might be a platform to develop such a
>> plugin. In this case I'd have a separate configuration bundle with my PID
>> cfgs in them and N levels of parent cfg files. The properties would just
>> be rolled up and written out into PID specific cfg files. If I define a
>> port or directory in a parent then all the children would inherit or
>> override that property. That would permit the use of profiles for dev,
>> test and production as well. Modifying any of the cfg files and then
>> putting that through Jenkins would result in a nice configuration bundle
>> that once reinstalled would trigger a reload. In the end the port or
>> directory or endpoint configuration information would be duplicated in each
>> cfg but it wouldn't require hand massaging of each cfg to change.
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Properties cfg wish...
Posted by Christian Schneider <ch...@die-schneider.net>.
Can you give some examples of typical config properties that need to be
shared between these bundles. Maybe they lead to an idea for a different
design.
Christian
On 08.07.2016 15:09, Brad Johnson wrote:
> Christian,
>
> Thanks for the feedback. I'm actually looking for a bit more robust
> solution. Just the one small project I'm working on now has 12
> business processes with a number of OSGi services that provide
> cross-cutting concerns. In this case they are service like credit
> card authorization, refunds, etc. CXF front ends them with REST/SOAP
> and I use recipientList to route them. But each of those business
> processes use OSGi services that might call out to banks, PayPal,
> analytics services, etc. Keeping these nicely segregated in their own
> bundles makes them very testable for the routing, data transformation
> to/from canonical form, etc. But configuration management is a bit of
> a pain because of the PID pinning. I use update strategy reload on
> the bundles so that configurations can be changed in different
> environments.
>
> Until now I've kept my configuration files in each bundle and pop them
> out using the features install mechanism. But I'm rethinking that
> based on these discussions. I don't know if the Maven properties
> plugin would do what I'm thinking about but it might be a platform to
> develop such a plugin. In this case I'd have a separate configuration
> bundle with my PID cfgs in them and N levels of parent cfg files. The
> properties would just be rolled up and written out into PID specific
> cfg files. If I define a port or directory in a parent then all the
> children would inherit or override that property. That would permit
> the use of profiles for dev, test and production as well. Modifying
> any of the cfg files and then putting that through Jenkins would
> result in a nice configuration bundle that once reinstalled would
> trigger a reload. In the end the port or directory or endpoint
> configuration information would be duplicated in each cfg but it
> wouldn't require hand massaging of each cfg to change.
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
Christian,
Thanks for the feedback. I'm actually looking for a bit more robust
solution. Just the one small project I'm working on now has 12 business
processes with a number of OSGi services that provide cross-cutting
concerns. In this case they are service like credit card authorization,
refunds, etc. CXF front ends them with REST/SOAP and I use recipientList
to route them. But each of those business processes use OSGi services that
might call out to banks, PayPal, analytics services, etc. Keeping these
nicely segregated in their own bundles makes them very testable for the
routing, data transformation to/from canonical form, etc. But
configuration management is a bit of a pain because of the PID pinning. I
use update strategy reload on the bundles so that configurations can be
changed in different environments.
Until now I've kept my configuration files in each bundle and pop them out
using the features install mechanism. But I'm rethinking that based on
these discussions. I don't know if the Maven properties plugin would do
what I'm thinking about but it might be a platform to develop such a
plugin. In this case I'd have a separate configuration bundle with my PID
cfgs in them and N levels of parent cfg files. The properties would just
be rolled up and written out into PID specific cfg files. If I define a
port or directory in a parent then all the children would inherit or
override that property. That would permit the use of profiles for dev,
test and production as well. Modifying any of the cfg files and then
putting that through Jenkins would result in a nice configuration bundle
that once reinstalled would trigger a reload. In the end the port or
directory or endpoint configuration information would be duplicated in each
cfg but it wouldn't require hand massaging of each cfg to change.
On Fri, Jul 8, 2016 at 7:38 AM, Christian Schneider <chris@die-schneider.net
> wrote:
> If you only need very generic configs then using a System property is also
> a good choice. You can not change these at runtime but
> Aries blueprint can use System properties quite conveniently.
>
> Christian
>
> On 08.07.2016 14:11, Brad Johnson wrote:
>
>> David B,
>>
>> The Configurator looks like it is on a good track. I'll have to re-read
>> to grok all the implications. Interestingly this made me think of an
>> interim work around for some of the issues identified in the paper with the
>> way the file based blueprint cfg mechanics work. Currently I associate my
>> cfg files with my bundles and use features to install and rename them.
>>
>> But if those cfg files for a subsystem existed in the same bundle then it
>> would be easy to create a plugin to merge parent->child properties into the
>> final pid.cfg file. Reinstalling the bundle would then trigger a reload on
>> bundles specifying that update strategy. One would still end up with one
>> bundle/one PID cfg in the end bound to the blueprint properties. But to
>> modify something like a common URI for a file location or endpoint could
>> happen in a parent cfg file that is then compiled into the various concrete
>> PID.cfgs, put into the bundle, and then installed into the system (with
>> overwrite = true).
>>
>> Not an ideal way of doing this perhaps but maybe a way to work around the
>> limitations imposed by blueprint's lack of support of multilocations and
>> single PID binding. That could also make creating dev/test/production
>> configuration bundles easier since that could be a settable parameter.
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Properties cfg wish...
Posted by Christian Schneider <ch...@die-schneider.net>.
If you only need very generic configs then using a System property is
also a good choice. You can not change these at runtime but
Aries blueprint can use System properties quite conveniently.
Christian
On 08.07.2016 14:11, Brad Johnson wrote:
> David B,
>
> The Configurator looks like it is on a good track. I'll have to
> re-read to grok all the implications. Interestingly this made me
> think of an interim work around for some of the issues identified in
> the paper with the way the file based blueprint cfg mechanics work.
> Currently I associate my cfg files with my bundles and use features to
> install and rename them.
>
> But if those cfg files for a subsystem existed in the same bundle then
> it would be easy to create a plugin to merge parent->child properties
> into the final pid.cfg file. Reinstalling the bundle would then
> trigger a reload on bundles specifying that update strategy. One
> would still end up with one bundle/one PID cfg in the end bound to the
> blueprint properties. But to modify something like a common URI for a
> file location or endpoint could happen in a parent cfg file that is
> then compiled into the various concrete PID.cfgs, put into the bundle,
> and then installed into the system (with overwrite = true).
>
> Not an ideal way of doing this perhaps but maybe a way to work around
> the limitations imposed by blueprint's lack of support of
> multilocations and single PID binding. That could also make creating
> dev/test/production configuration bundles easier since that could be a
> settable parameter.
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
David B,
The Configurator looks like it is on a good track. I'll have to re-read to
grok all the implications. Interestingly this made me think of an interim
work around for some of the issues identified in the paper with the way the
file based blueprint cfg mechanics work. Currently I associate my cfg
files with my bundles and use features to install and rename them.
But if those cfg files for a subsystem existed in the same bundle then it
would be easy to create a plugin to merge parent->child properties into the
final pid.cfg file. Reinstalling the bundle would then trigger a reload on
bundles specifying that update strategy. One would still end up with one
bundle/one PID cfg in the end bound to the blueprint properties. But to
modify something like a common URI for a file location or endpoint could
happen in a parent cfg file that is then compiled into the various concrete
PID.cfgs, put into the bundle, and then installed into the system (with
overwrite = true).
Not an ideal way of doing this perhaps but maybe a way to work around the
limitations imposed by blueprint's lack of support of multilocations and
single PID binding. That could also make creating dev/test/production
configuration bundles easier since that could be a settable parameter.
On Fri, Jul 8, 2016 at 3:50 AM, David Bosschaert <david.bosschaert@gmail.com
> 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 <br...@mediadriver.com>
> 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
>>
>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
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 <david.bosschaert@gmail.com
> wrote:
> Hi Brad,
>
> On the 'Blueprint is dead' discussion... There are a number of RFCs in
> OSGi about improving blueprint [1][2][3][4][5], but they have not made it
> to the specs yet because those pushing them forward ended up being
> reassigned to other work. Anyone who is a member of OSGi can certainly pick
> those up and bring 'Blueprint back to life'... OTOH a lot of work has gone
> into Declarative Services over the recent past so if someone was to start
> from scratch it would make most sense to use DS today...
>
> Best regards,
>
> David
>
> [1] https://github.com/osgi/design/tree/master/rfcs/rfc0155
> [2] https://github.com/osgi/design/tree/master/rfcs/rfc0156
> [3] https://github.com/osgi/design/tree/master/rfcs/rfc0164
> [4] https://github.com/osgi/design/tree/master/rfcs/rfc0166
> [5] https://github.com/osgi/design/tree/master/rfcs/rfc0184
>
> On 8 July 2016 at 11:24, Brad Johnson <br...@mediadriver.com>
> 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 <
>> david.bosschaert@gmail.com> 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 <br...@mediadriver.com>
>>> 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
>>>>
>>>
>>>
>>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
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 <chris@die-schneider.net
> 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
>
> [1] https://github.com/osgi/design/tree/master/rfcs/rfc0155
> [2] https://github.com/osgi/design/tree/master/rfcs/rfc0156
> [3] https://github.com/osgi/design/tree/master/rfcs/rfc0164
> [4] https://github.com/osgi/design/tree/master/rfcs/rfc0166
> [5] https://github.com/osgi/design/tree/master/rfcs/rfc0184
>
> On 8 July 2016 at 11:24, Brad Johnson <br...@mediadriver.com>
> 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 <
>> <da...@gmail.com> 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>
>>> 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 < <br...@mediadriver.com>
>>> brad.johnson@mediadriver.com> 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 Schneiderhttp://www.liquid-reality.de
>
> Open Source Architecthttp://www.talend.com
>
>
Re: Properties cfg wish...
Posted by Christian Schneider <ch...@die-schneider.net>.
I think one really big problem with the OSGi specs is that only people
working for an OSGi alliance member can work on specs.
Especially in the open source world there are a lot of motivated people
with good knowledge but if their employer is not an OSGi member these
people can not work on any spec.
So while I can understand that only the OSGi members decide about the
specs in the end I think the OSGi alliance must open itself more for
individuals who are offering to help. Only in this way
the OSGi alliance can keep up with the dynamics of open source.
Having saig all this I am not sure though if it would really help with
blueprint. In the case of blueprint my impression is that it has grown
too complex while still having some severe drawbacks in practice.
So I myself are currently looking more into DS as it is simpler and has
less issues with all the OSGi dynamics. I think DS might need a defined
extension model but in its core I really like that
it kept being quite simple.
Christian
On 08.07.2016 12:37, David Bosschaert wrote:
> Hi Brad,
>
> On the 'Blueprint is dead' discussion... There are a number of RFCs in
> OSGi about improving blueprint [1][2][3][4][5], but they have not made
> it to the specs yet because those pushing them forward ended up being
> reassigned to other work. Anyone who is a member of OSGi can certainly
> pick those up and bring 'Blueprint back to life'... OTOH a lot of work
> has gone into Declarative Services over the recent past so if someone
> was to start from scratch it would make most sense to use DS today...
>
> Best regards,
>
> David
>
> [1] https://github.com/osgi/design/tree/master/rfcs/rfc0155
> [2] https://github.com/osgi/design/tree/master/rfcs/rfc0156
> [3] https://github.com/osgi/design/tree/master/rfcs/rfc0164
> [4] https://github.com/osgi/design/tree/master/rfcs/rfc0166
> [5] https://github.com/osgi/design/tree/master/rfcs/rfc0184
>
> On 8 July 2016 at 11:24, Brad Johnson <brad.johnson@mediadriver.com
> <ma...@mediadriver.com>> 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
> <david.bosschaert@gmail.com <ma...@gmail.com>>
> 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
> <brad.johnson@mediadriver.com
> <ma...@mediadriver.com>> 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
Re: Properties cfg wish...
Posted by David Bosschaert <da...@gmail.com>.
Hi Brad,
On the 'Blueprint is dead' discussion... There are a number of RFCs in OSGi
about improving blueprint [1][2][3][4][5], but they have not made it to the
specs yet because those pushing them forward ended up being reassigned to
other work. Anyone who is a member of OSGi can certainly pick those up and
bring 'Blueprint back to life'... OTOH a lot of work has gone into
Declarative Services over the recent past so if someone was to start from
scratch it would make most sense to use DS today...
Best regards,
David
[1] https://github.com/osgi/design/tree/master/rfcs/rfc0155
[2] https://github.com/osgi/design/tree/master/rfcs/rfc0156
[3] https://github.com/osgi/design/tree/master/rfcs/rfc0164
[4] https://github.com/osgi/design/tree/master/rfcs/rfc0166
[5] https://github.com/osgi/design/tree/master/rfcs/rfc0184
On 8 July 2016 at 11:24, Brad Johnson <br...@mediadriver.com> 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 <
> david.bosschaert@gmail.com> 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 <br...@mediadriver.com>
>> 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
>>>
>>
>>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
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 <david.bosschaert@gmail.com
> 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 <br...@mediadriver.com>
> 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
>>
>
>
Re: Properties cfg wish...
Posted by David Bosschaert <da...@gmail.com>.
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 <br...@mediadriver.com> 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
>
RE: Properties cfg wish...
Posted by CLEMENT Jean-Philippe <je...@fr.thalesgroup.com>.
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:david_jencks@yahoo.com]
Envoyé : jeudi 7 juillet 2016 23:48
À : user@aries.apache.org
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 <br...@mediadriver.com>> 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 <br...@mediadriver.com>> 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 <da...@yahoo.com>> 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 <br...@mediadriver.com>> 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
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
Incidentally just so this doesn't sound like a complete whinefest, I think
Blueprint is in much better shape than it was 3 years ago. Even small
things like the update-strategy on the CM properties help.
CamelBlueprintTestSupport was pretty rocky awhile back with tests that
would arbitrarily hang.
And SCR with Camel seems like Blueprint was 3 or 4 years ago.
On Fri, Jul 8, 2016 at 6:21 AM, Brad Johnson <br...@mediadriver.com>
wrote:
> I meant my own OSGi services that I register and pull from the registry.
> Not Camel core components.
>
> Trust me I don't have a great love of Blueprint but I haven't seen any
> solutions using DS and Camel that I thought were "ooh, I just have to do it
> that way".
>
> On Fri, Jul 8, 2016 at 6:14 AM, Christian Schneider <
> chris@die-schneider.net> wrote:
>
>> > 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
>>
>>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
I meant my own OSGi services that I register and pull from the registry.
Not Camel core components.
Trust me I don't have a great love of Blueprint but I haven't seen any
solutions using DS and Camel that I thought were "ooh, I just have to do it
that way".
On Fri, Jul 8, 2016 at 6:14 AM, Christian Schneider <chris@die-schneider.net
> wrote:
> > 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
>
>
Re: Properties cfg wish...
Posted by Christian Schneider <ch...@die-schneider.net>.
> 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
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
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 <chris@die-schneider.net
> 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 < <br...@mediadriver.com>
> brad.johnson@mediadriver.com> 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 < <da...@yahoo.com>
> david_jencks@yahoo.com> 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 <
>> <br...@mediadriver.com> 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 <
>> <br...@mediadriver.com> 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 < <da...@yahoo.com>
>>> david_jencks@yahoo.com> 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 <
>>>> <br...@mediadriver.com> 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 Schneiderhttp://www.liquid-reality.de
>
> Open Source Architecthttp://www.talend.com
>
>
Re: Properties cfg wish...
Posted by Christian Schneider <ch...@die-schneider.net>.
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
>> <brad.johnson@mediadriver.com <ma...@mediadriver.com>>
>> 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 <david_jencks@yahoo.com
>> <ma...@yahoo.com>> wrote:
>>
>> Well, its the user list rather than dev list, but that\u2019s 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 \u2014 just because I don\u2019t see
>> them doesn\u2019t mean they aren\u2019t there.
>>
>> Finally, I\u2019m 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
>>> <brad.johnson@mediadriver.com
>>> <ma...@mediadriver.com>> 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
>>> <brad.johnson@mediadriver.com
>>> <ma...@mediadriver.com>> 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
>>> <david_jencks@yahoo.com <ma...@yahoo.com>> 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\u2019s fairly ridiculous that after all these years
>>> blueprint\u2019s relationship to config admin is unspecified.
>>> I think that there are no \u201cblueprint people\u201d 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\u2019t 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\u2019t 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
>>> \u201cnames" 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\u2019t 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
>>> <brad.johnson@mediadriver.com
>>> <ma...@mediadriver.com>> 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
Re: Properties cfg wish...
Posted by David Jencks <da...@yahoo.com>.
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 <br...@mediadriver.com> 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 <david_jencks@yahoo.com <ma...@yahoo.com>> 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 <brad.johnson@mediadriver.com <ma...@mediadriver.com>> 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 <brad.johnson@mediadriver.com <ma...@mediadriver.com>> 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 <david_jencks@yahoo.com <ma...@yahoo.com>> 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 <brad.johnson@mediadriver.com <ma...@mediadriver.com>> 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
>>
>>
>>
>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
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 <da...@yahoo.com> 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 <br...@mediadriver.com>
> 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 <brad.johnson@mediadriver.com
> > 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 <da...@yahoo.com>
>> 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 <
>>> brad.johnson@mediadriver.com> 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
>>>
>>>
>>
>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
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 <da...@yahoo.com> 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 <br...@mediadriver.com>
> 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 <brad.johnson@mediadriver.com
> > 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 <da...@yahoo.com>
>> 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 <
>>> brad.johnson@mediadriver.com> 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
>>>
>>>
>>
>
>
Re: Properties cfg wish...
Posted by David Jencks <da...@yahoo.com>.
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 <br...@mediadriver.com> 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 <brad.johnson@mediadriver.com <ma...@mediadriver.com>> 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 <david_jencks@yahoo.com <ma...@yahoo.com>> 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 <brad.johnson@mediadriver.com <ma...@mediadriver.com>> 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
>
>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
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 <br...@mediadriver.com>
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 <da...@yahoo.com>
> 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 <br...@mediadriver.com>
>> 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
>>
>>
>
Re: Properties cfg wish...
Posted by Brad Johnson <br...@mediadriver.com>.
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 <da...@yahoo.com> 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 <br...@mediadriver.com>
> 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
>
>
Re: Properties cfg wish...
Posted by David Jencks <da...@yahoo.com>.
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 <br...@mediadriver.com> 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