You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Pablo Gómez Pérez <pa...@faw.jku.at> on 2016/07/07 13:51:12 UTC
blueprint:cm multiple bundle but same config file
Hello All,
Is it possible to use same config file from multiple bundles
while using Config Admin with blueprint Blueprint? Because, I can't
manage to do that, I get the following error:
MESSAGE Cannot use configuration test.mybundle for
[org.osgi.service.cm.ManagedService, id=214,
bundle=86/initial@reference:file:../plugin-1/]: No visibility to
configuration bound to initial@reference:file:../plugin-2/
I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959
However, I fear that this is a problem in the aries blueprint
implementation as I'm not using KARAF nor FUSE, just a plain osgi
container. Either that or I'm missing some blueprint configuration. I'm
basically using blueprint:cm
As a workaround I can make a config file per bundle that needs it....
As follows the versions and bundles that I'm using related to the
container (Running on top of Equinox 3.11):
ID|State |Level|Name
5|Active | 2|Apache Aries Whiteboard support for JMX
DynamicMBean services (1.1.5)|1.1.5
6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
13|Active | 3|Aries Remote Service Admin Topology Manager
(1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
25|Active | 3|Aries Remote Service Admin Discovery Gogo
Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
Fragment Bundle (1.0.0)|1.0.0
55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
67|Active | 3|Aries Remote Service Admin Service Provider
Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes
(1.0.0)|1.0.0
88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
94|Active | 3|Aries Remote Service Admin Discovery Config
(1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
97|Active | 3|Aries Remote Service Admin provider TCP
(1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
130|Active | 2|Apache Aries Blueprint Annotation Impl
(1.0.1)|1.0.1
132|Active | 3|Aries Remote Service Admin Discovery Zookeeper
(1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
134|Active | 3|Aries Remote Service Admin Discovery Local
(1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
138|Active | 3|Aries Remote Service Admin Core
(1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
(1.0.8)|1.0.8
147|Active | 2|Aries JPA Container blueprint integration for
Aries blueprint (1.0.4)|1.0.4
11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
148|Active | 4|Apache Felix Configuration Admin Service
(1.8.8)|1.8.8
0|Active | 0|OSGi System Bundle
(3.11.0.v20160603-1336)|3.11.0.v20160603-1336
--
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
Aye, there's the rub. And obviously many of us aren't on the bleeding edge
of blueprint or OSGi either so some of these features may be new and in
place now. I've had to use work arounds for this in the past like creating
my own OSGi service to share configuration data.
On Thu, Jul 7, 2016 at 10:18 AM, Raymond Auge <ra...@liferay.com>
wrote:
> So I guess the question comes down to how configurable is blueprint in
> this regard!
>
> that's the part I don't know.
>
> - Ray
>
> On Thu, Jul 7, 2016 at 11:17 AM, David Jencks <da...@yahoo.com>
> wrote:
>
>> Neither one, the bundleLocation on the configuration is set. This is
>> something config admin deals with. The management agent that creates the
>> configuration should set the multi-location”?” when it creates the
>> configuration.
>>
>> david jencks
>>
>> On Jul 7, 2016, at 8:09 AM, Brad Johnson <br...@mediadriver.com>
>> wrote:
>>
>> Ray,
>>
>> When you say bound to the bundle do you mean that it physically resides
>> in the jar/bundle or do you mean bound via the blueprint properties
>> persistent-id?
>>
>> Brad
>>
>> On Thu, Jul 7, 2016 at 9:41 AM, Raymond Auge <ra...@liferay.com>
>> wrote:
>>
>>> As long as configurations are not bound to a bundle they can be used by
>>> any bundle.
>>>
>>> The exception clearly shows that the configuration is bound to a bundle.
>>>
>>> Creating an unbound configuration requires passing a "?" as the second
>>> arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>>
>>>
>>> HTH,
>>> - Ray
>>>
>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>> brad.johnson@mediadriver.com> wrote:
>>>
>>>> I don't think that's possible.
>>>>
>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>> pablo.gomez@faw.jku.at> wrote:
>>>>
>>>>> Hello All,
>>>>>
>>>>> Is it possible to use same config file from multiple bundles
>>>>> while using Config Admin with blueprint Blueprint? Because, I can't manage
>>>>> to do that, I get the following error:
>>>>>
>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>> bundle=86/initial@reference:file:../plugin-1/]: No visibility to
>>>>> configuration bound to initial@reference:file:../plugin-2/
>>>>>
>>>>>
>>>>> I saw in this jira a bug opened:
>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>
>>>>>
>>>>> However, I fear that this is a problem in the aries blueprint
>>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>> basically using blueprint:cm
>>>>>
>>>>>
>>>>> As a workaround I can make a config file per bundle that needs it....
>>>>>
>>>>> As follows the versions and bundles that I'm using related to the
>>>>> container (Running on top of Equinox 3.11):
>>>>>
>>>>> ID|State |Level|Name
>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>>>> DynamicMBean services (1.1.5)|1.1.5
>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager
>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo
>>>>> Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
>>>>> Fragment Bundle (1.0.0)|1.0.0
>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>>> (1.0.4)|1.0.4
>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>> 67|Active | 3|Aries Remote Service Admin Service Provider
>>>>> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>> (1.1.1)|1.1.1
>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes
>>>>> (1.0.0)|1.0.0
>>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config
>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>>> (1.0.1)|1.0.1
>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>> (2.1.0)|2.1.0
>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>>>> (1.0.1)|1.0.1
>>>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper
>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local
>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
>>>>> (1.0.8)|1.0.8
>>>>> 147|Active | 2|Aries JPA Container blueprint integration for
>>>>> Aries blueprint (1.0.4)|1.0.4
>>>>>
>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>> (1.2.8)|1.2.8
>>>>> 148|Active | 4|Apache Felix Configuration Admin Service
>>>>> (1.8.8)|1.8.8
>>>>>
>>>>> 0|Active | 0|OSGi System Bundle
>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>
>>>>>
>>>>> --
>>>>> WARNING: Computer viruses can be transmitted via email. The recipient
>>>>> should check this email and any attachments for the presence of viruses.
>>>>> The company accepts no liability for any damage caused by any virus
>>>>> transmitted by this email. E-mail transmission cannot be guaranteed to be
>>>>> secure or error-free as information could be intercepted, corrupted, lost,
>>>>> destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>> therefore does not accept liability for any errors or omissions in the
>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>
>>>>> Warning: Although the company has taken reasonable precautions to
>>>>> ensure no viruses are present in this email, the company cannot accept
>>>>> responsibility for any loss or damage arising from the use of this email or
>>>>> attachments.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>> (@OSGiAlliance)
>>>
>>
>>
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
Re: blueprint:cm multiple bundle but same config file
Posted by David Jencks <da...@yahoo.com>.
I’d say the first question is whether common management agents (felix fileinstall???) let you specify the bundle location. The second is whether blueprint cm accepts the “?” multi-location.
david jencks
> On Jul 7, 2016, at 8:18 AM, Raymond Auge <ra...@liferay.com> wrote:
>
> So I guess the question comes down to how configurable is blueprint in this regard!
>
> that's the part I don't know.
>
> - Ray
>
> On Thu, Jul 7, 2016 at 11:17 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
> Neither one, the bundleLocation on the configuration is set. This is something config admin deals with. The management agent that creates the configuration should set the multi-location”?” when it creates the configuration.
>
> david jencks
>
>> On Jul 7, 2016, at 8:09 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>
>> Ray,
>>
>> When you say bound to the bundle do you mean that it physically resides in the jar/bundle or do you mean bound via the blueprint properties persistent-id?
>>
>> Brad
>>
>> On Thu, Jul 7, 2016 at 9:41 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
>> As long as configurations are not bound to a bundle they can be used by any bundle.
>>
>> The exception clearly shows that the configuration is bound to a bundle.
>>
>> Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>
>>
>> HTH,
>> - Ray
>>
>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>> I don't think that's possible.
>>
>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>> Hello All,
>>
>> Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
>>
>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm <http://org.osgi.service.cm/>.ManagedService, id=214, bundle=86/initial@reference:file:../plugin-1/]: No visibility to configuration bound to initial@reference:file:../plugin-2/
>>
>>
>> I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959 <https://issues.jboss.org/browse/ENTESB-3959>
>>
>>
>> However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
>>
>>
>> As a workaround I can make a config file per bundle that needs it....
>>
>> As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
>>
>> ID|State |Level|Name
>> 5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>> 13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>> 67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>> 94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>> 130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
>> 147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
>>
>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
>> 148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
>>
>> 0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>
>>
>> --
>> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
>>
>> Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>>
>>
>>
>>
>> --
>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>
>
>
>
>
> --
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
Re: blueprint:cm multiple bundle but same config file
Posted by Raymond Auge <ra...@liferay.com>.
So I guess the question comes down to how configurable is blueprint in this
regard!
that's the part I don't know.
- Ray
On Thu, Jul 7, 2016 at 11:17 AM, David Jencks <da...@yahoo.com>
wrote:
> Neither one, the bundleLocation on the configuration is set. This is
> something config admin deals with. The management agent that creates the
> configuration should set the multi-location”?” when it creates the
> configuration.
>
> david jencks
>
> On Jul 7, 2016, at 8:09 AM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
> Ray,
>
> When you say bound to the bundle do you mean that it physically resides in
> the jar/bundle or do you mean bound via the blueprint properties
> persistent-id?
>
> Brad
>
> On Thu, Jul 7, 2016 at 9:41 AM, Raymond Auge <ra...@liferay.com>
> wrote:
>
>> As long as configurations are not bound to a bundle they can be used by
>> any bundle.
>>
>> The exception clearly shows that the configuration is bound to a bundle.
>>
>> Creating an unbound configuration requires passing a "?" as the second
>> arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>
>>
>> HTH,
>> - Ray
>>
>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>> brad.johnson@mediadriver.com> wrote:
>>
>>> I don't think that's possible.
>>>
>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>> pablo.gomez@faw.jku.at> wrote:
>>>
>>>> Hello All,
>>>>
>>>> Is it possible to use same config file from multiple bundles
>>>> while using Config Admin with blueprint Blueprint? Because, I can't manage
>>>> to do that, I get the following error:
>>>>
>>>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm.ManagedService,
>>>> id=214, bundle=86/initial@reference:file:../plugin-1/]: No visibility
>>>> to configuration bound to initial@reference:file:../plugin-2/
>>>>
>>>>
>>>> I saw in this jira a bug opened:
>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>
>>>>
>>>> However, I fear that this is a problem in the aries blueprint
>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>> basically using blueprint:cm
>>>>
>>>>
>>>> As a workaround I can make a config file per bundle that needs it....
>>>>
>>>> As follows the versions and bundles that I'm using related to the
>>>> container (Running on top of Equinox 3.11):
>>>>
>>>> ID|State |Level|Name
>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>>> DynamicMBean services (1.1.5)|1.1.5
>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager
>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo
>>>> Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
>>>> Fragment Bundle (1.0.0)|1.0.0
>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>> (1.0.4)|1.0.4
>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>> 67|Active | 3|Aries Remote Service Admin Service Provider
>>>> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes
>>>> (1.0.0)|1.0.0
>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config
>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>> (1.0.1)|1.0.1
>>>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>>> (1.0.1)|1.0.1
>>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper
>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local
>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
>>>> (1.0.8)|1.0.8
>>>> 147|Active | 2|Aries JPA Container blueprint integration for
>>>> Aries blueprint (1.0.4)|1.0.4
>>>>
>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>> 114|Active | 4|Apache Felix Web Management Console
>>>> (1.2.8)|1.2.8
>>>> 148|Active | 4|Apache Felix Configuration Admin Service
>>>> (1.8.8)|1.8.8
>>>>
>>>> 0|Active | 0|OSGi System Bundle
>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>
>>>>
>>>> --
>>>> WARNING: Computer viruses can be transmitted via email. The recipient
>>>> should check this email and any attachments for the presence of viruses.
>>>> The company accepts no liability for any damage caused by any virus
>>>> transmitted by this email. E-mail transmission cannot be guaranteed to be
>>>> secure or error-free as information could be intercepted, corrupted, lost,
>>>> destroyed, arrive late or incomplete, or contain viruses. The sender
>>>> therefore does not accept liability for any errors or omissions in the
>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>
>>>> Warning: Although the company has taken reasonable precautions to
>>>> ensure no viruses are present in this email, the company cannot accept
>>>> responsibility for any loss or damage arising from the use of this email or
>>>> attachments.
>>>>
>>>
>>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>> (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>> (@OSGiAlliance)
>>
>
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: blueprint:cm multiple bundle but same config file
Posted by David Jencks <da...@yahoo.com>.
Neither one, the bundleLocation on the configuration is set. This is something config admin deals with. The management agent that creates the configuration should set the multi-location”?” when it creates the configuration.
david jencks
> On Jul 7, 2016, at 8:09 AM, Brad Johnson <br...@mediadriver.com> wrote:
>
> Ray,
>
> When you say bound to the bundle do you mean that it physically resides in the jar/bundle or do you mean bound via the blueprint properties persistent-id?
>
> Brad
>
> On Thu, Jul 7, 2016 at 9:41 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
> As long as configurations are not bound to a bundle they can be used by any bundle.
>
> The exception clearly shows that the configuration is bound to a bundle.
>
> Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
>
>
> HTH,
> - Ray
>
> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
> I don't think that's possible.
>
> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
> Hello All,
>
> Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
>
> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm <http://org.osgi.service.cm/>.ManagedService, id=214, bundle=86/initial@reference:file:../plugin-1/]: No visibility to configuration bound to initial@reference:file:../plugin-2/
>
>
> I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959 <https://issues.jboss.org/browse/ENTESB-3959>
>
>
> However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
>
>
> As a workaround I can make a config file per bundle that needs it....
>
> As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
>
> ID|State |Level|Name
> 5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
> 13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
> 67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
> 94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
> 130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
> 147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
>
> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
> 148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
>
> 0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>
>
> --
> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
>
> Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>
>
>
>
> --
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
Ray,
When you say bound to the bundle do you mean that it physically resides in
the jar/bundle or do you mean bound via the blueprint properties
persistent-id?
Brad
On Thu, Jul 7, 2016 at 9:41 AM, Raymond Auge <ra...@liferay.com>
wrote:
> As long as configurations are not bound to a bundle they can be used by
> any bundle.
>
> The exception clearly shows that the configuration is bound to a bundle.
>
> Creating an unbound configuration requires passing a "?" as the second
> arguments to getConfiguration/createFactoryConfiguration methods of CM.
>
>
> HTH,
> - Ray
>
> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
> brad.johnson@mediadriver.com> wrote:
>
>> I don't think that's possible.
>>
>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at
>> > wrote:
>>
>>> Hello All,
>>>
>>> Is it possible to use same config file from multiple bundles
>>> while using Config Admin with blueprint Blueprint? Because, I can't manage
>>> to do that, I get the following error:
>>>
>>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm.ManagedService,
>>> id=214, bundle=86/initial@reference:file:../plugin-1/]: No visibility
>>> to configuration bound to initial@reference:file:../plugin-2/
>>>
>>>
>>> I saw in this jira a bug opened:
>>> https://issues.jboss.org/browse/ENTESB-3959
>>>
>>>
>>> However, I fear that this is a problem in the aries blueprint
>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>> container. Either that or I'm missing some blueprint configuration. I'm
>>> basically using blueprint:cm
>>>
>>>
>>> As a workaround I can make a config file per bundle that needs it....
>>>
>>> As follows the versions and bundles that I'm using related to the
>>> container (Running on top of Equinox 3.11):
>>>
>>> ID|State |Level|Name
>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>> DynamicMBean services (1.1.5)|1.1.5
>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>> 13|Active | 3|Aries Remote Service Admin Topology Manager
>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo
>>> Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
>>> Fragment Bundle (1.0.0)|1.0.0
>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>> (1.0.4)|1.0.4
>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>> 67|Active | 3|Aries Remote Service Admin Service Provider
>>> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes
>>> (1.0.0)|1.0.0
>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>> 94|Active | 3|Aries Remote Service Admin Discovery Config
>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>> (1.0.1)|1.0.1
>>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>> (1.0.1)|1.0.1
>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper
>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 134|Active | 3|Aries Remote Service Admin Discovery Local
>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 138|Active | 3|Aries Remote Service Admin Core
>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
>>> (1.0.8)|1.0.8
>>> 147|Active | 2|Aries JPA Container blueprint integration for
>>> Aries blueprint (1.0.4)|1.0.4
>>>
>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
>>> 148|Active | 4|Apache Felix Configuration Admin Service
>>> (1.8.8)|1.8.8
>>>
>>> 0|Active | 0|OSGi System Bundle
>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>
>>>
>>> --
>>> WARNING: Computer viruses can be transmitted via email. The recipient
>>> should check this email and any attachments for the presence of viruses.
>>> The company accepts no liability for any damage caused by any virus
>>> transmitted by this email. E-mail transmission cannot be guaranteed to be
>>> secure or error-free as information could be intercepted, corrupted, lost,
>>> destroyed, arrive late or incomplete, or contain viruses. The sender
>>> therefore does not accept liability for any errors or omissions in the
>>> contents of this message, which arise as a result of e-mail transmission.
>>>
>>> Warning: Although the company has taken reasonable precautions to ensure
>>> no viruses are present in this email, the company cannot accept
>>> responsibility for any loss or damage arising from the use of this email or
>>> attachments.
>>>
>>
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
Re: blueprint:cm multiple bundle but same config file
Posted by David Jencks <da...@yahoo.com>.
Well, that is a bit imprecise. Also you need at least an R5 compliant config admin implementation.
To get a truly unbound configuration, you pass null as the second argument (and hope no one has persistently bound the configuration). It’s better to pass “?” or other multi-location as that won’t be accidentally bound by someone calling getConfiguration(pid).
Multi-locations all start with “?” and may also have a symbolic name appended, which is only relevant if you have security on. Read the details in the cmpn 104.4.1.
Even with an R5 config admin, it’s possible that the (unspecced) blueprint:cm code won’t work with multi locations.. I’d consider this a bug.
david jencks
> On Jul 7, 2016, at 7:41 AM, Raymond Auge <ra...@liferay.com> wrote:
>
> As long as configurations are not bound to a bundle they can be used by any bundle.
>
> The exception clearly shows that the configuration is bound to a bundle.
>
> Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
>
>
> HTH,
> - Ray
>
> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
> I don't think that's possible.
>
> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
> Hello All,
>
> Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
>
> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm <http://org.osgi.service.cm/>.ManagedService, id=214, bundle=86/initial@reference:file:../plugin-1/]: No visibility to configuration bound to initial@reference:file:../plugin-2/
>
>
> I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959 <https://issues.jboss.org/browse/ENTESB-3959>
>
>
> However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
>
>
> As a workaround I can make a config file per bundle that needs it....
>
> As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
>
> ID|State |Level|Name
> 5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
> 13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
> 67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
> 94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
> 130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
> 147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
>
> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
> 148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
>
> 0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>
>
> --
> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
>
> Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>
>
>
>
> --
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
Re: blueprint:cm multiple bundle but same config file
Posted by David Jencks <da...@yahoo.com>.
My point is that should you wish to investigate this the place to start is finding the code that takes the .cfg file and uses it to create or modify a configuration in config admin, and find out whether it can set the bundle location to “?”. After you get that working then you can see if the config admin implementation you are using or blueprint cm is doing anything else to thwart you.
thanks
david jencks
> On Jul 7, 2016, at 10:37 AM, Brad Johnson <br...@mediadriver.com> wrote:
>
> Ray,
>
> If I understand your question right the answer is the Aries extension is referencing configuration. In karaf/fuse for example the following:
>
> <cm:property-placeholder persistent-id="com.my.foo" update-strategy="reload">
>
> will load properties from etc/com.my.foo.cfg
>
> Installing that file is done either manually or by use of a features file.
>
> Whenever I've attempted to use the PID in more than one bundle it has failed and I don't think it is permitted. That's a problem I think and something that should be fixed through some other configuration management mechanism. Making microservices that might share common properties, for example, becomes problematic in that regard and I've resorted to using my own OSGi services to overcome that problem.
>
> Brad
>
> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
> Ok, so after a brief review the cm schema is an Aries extension and it doesn't appear to support the location binding.
>
> However, it's unclear to me whether this extension is creating the configuration or merely referencing one from outside.
>
> Any Aries gurus can answer that?
>
> - Ray
>
> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
> I’m not really familiar with blueprint cm but I’d expect that to indicate which pid to use to fetch the config from config admin and in the ... how to map configuration propertiething blueprint substitution knows about. Is that really instructions to create a new configuration and populate it with data (what a management agent does)?
>
> david jencks
>
>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
>>
>> David, I agree with everything you've said, however this looks like blueprint being the agent here:
>>
>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>> ...
>> </cm:property-placeholder>
>>
>> - Ray
>>
>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>> No, blueprint cm shouldn’t really know about the multi-location. The management agent that is creating the configuration should be setting the bundle location to the multi-location ”?”.
>>
>> david jencks
>>
>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>>
>>> I see and would it possible to configure which method is invoked from Blueprint?
>>>
>>> This is how I do it:
>>>
>>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>>> ...
>>> </cm:property-placeholder>
>>>
>>> is there perhaps some blueprint property where I can tune the second argument in the createFactoryConfiguration?
>>>
>>> Because it looks like the fact of using config admin through blueprint binds the PID to the first bundle using it
>>>
>>>
>>> best
>>> Pablo
>>>
>>>
>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>> As long as configurations are not bound to a bundle they can be used by any bundle.
>>>>
>>>> The exception clearly shows that the configuration is bound to a bundle.
>>>>
>>>> Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>>>
>>>>
>>>> HTH,
>>>> - Ray
>>>>
>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>> I don't think that's possible.
>>>>
>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>>> Hello All,
>>>>
>>>> Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
>>>>
>>>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm <http://org.osgi.service.cm/>.ManagedService, id=214, bundle=86/initial@reference:file:../plugin-1/ <mailto:bundle=86/initial@reference:file:../plugin-1/>]: No visibility to configuration bound to initial@reference:file:../plugin-2/ <mailto:initial@reference:file:../plugin-2/>
>>>>
>>>>
>>>> I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959 <https://issues.jboss.org/browse/ENTESB-3959>
>>>>
>>>>
>>>> However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
>>>>
>>>>
>>>> As a workaround I can make a config file per bundle that needs it....
>>>>
>>>> As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
>>>>
>>>> ID|State |Level|Name
>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>> 67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
>>>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
>>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
>>>> 147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
>>>>
>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
>>>> 148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
>>>>
>>>> 0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>
>>>>
>>>> --
>>>> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
>>>>
>>>> Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>>
>>
>>
>>
>>
>> --
>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>
>
>
>
> --
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>
Re: blueprint:cm multiple bundle but same config file
Posted by jgenender <jg...@apache.org>.
Wow... that answer surprises me. My business works exclusively with Karaf,
ServiceMix, ActiveMQ, CXF, and Camel. A large portion of it is heavily OSGi
based. In all of my years, I still have yet to run into a single DS
implementation, and I actually only heard of one that was used and was
subsequently gutted and replaced with BP.
DJ, are you speaking from experience on the DS when you say you don't think
there are really any BP folks? Because *all* of the people we run into use
BP. I find your argument the exact opposite.
--
View this message in context: http://aries.15396.n3.nabble.com/blueprint-cm-multiple-bundle-but-same-config-file-tp4033324p4033348.html
Sent from the Aries - User mailing list archive at Nabble.com.
Re: blueprint:cm multiple bundle but same config file
Posted by Guillaume Nodet <gn...@apache.org>.
THere's not much to document, it basically provides
- support for spring and custom spring namespaces (by deploying the
aries blueprint-spring bundle)
- support for Spring-OSGi bundles (with the additional
blueprint-spring-extender bundle)
The idea is to have full support for both, so if you need any information,
you should go and look at the spring docs.
I'd be happy to answer any specific question you may have or any problem
you encounter in your experiments...
Guillaume
2016-07-13 10:42 GMT+02:00 CLEMENT Jean-Philippe <
jean-philippe.clement@fr.thalesgroup.com>:
> Hi Guillaume,
>
>
>
> Your “I've recently added a bunch of important features related to spring
> in blueprint” sounds promising. Are there some documentation of those new
> features?
>
>
>
> Regards,
>
> JP
>
>
>
> *De :* Guillaume Nodet [mailto:gnodet@apache.org]
> *Envoyé :* mardi 12 juillet 2016 17:58
> *À :* user@aries.apache.org
> *Objet :* Re: blueprint:cm multiple bundle but same config file
>
>
>
> I can happily review a patch if you're fancy writing one...
>
>
>
> And I disagree with the 'blueprint is dead and nobody cares about it
> anymore'. What's dead is the blueprint osgi specification for blueprint,
> not the Aries Blueprint project. I've recently added a bunch of important
> features related to spring in blueprint.
>
>
>
> DS also has some drawbacks as it's not extensible at all : this is leading
> the OSGi Alliance to write a new spec for transaction support !!!
>
>
>
> I think the CDI+DS extension I've been working on those past weeks could
> bring the best of both world : strong DS semantics for the OSGi bits, but
> extensibility and support for proxies provided by CDI ;-)
>
>
>
>
>
> 2016-07-12 17:24 GMT+02:00 Brad Johnson <br...@mediadriver.com>:
>
> David,
>
>
>
> I'm all for multilocation support in blueprint. Can't wait for it. But
> it sounds like your saying blueprint is dead and nobody cares about it
> anymore so it doesn't seem likely to happen anytime soon. It certainly
> wouldn't be relevant to Fuse which uses R4 in any case.
>
>
>
> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <
> brad.johnson@mediadriver.com> wrote:
>
> The features file can have statements like this:
>
>
>
>
>
> <configfile finalname="/etc/com.foo.cfg"
> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
>
> <configfile finalname="/etc/com.bar.cfg"
> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
>
> ....etc....
>
> That's off the top of my head so take it with a grain of salt for syntax.
>
>
>
> When you run the features install it will overwrite the files in the etc
> directory with the ones in the maven bundle which have now been updated. So
> instead of modifying configuration files in the etc directory you modifying
> them in your Maven configuration project and recompile the bundle and then
> pull it from the repo
>
> in order to update the values.
>
>
>
> But you can still modify them in the etc if you wanted. You just have to
> make sure you have the cm properties set to reload.
>
>
>
> <cm:property-placeholder persistent-id="com.foo" update-strategy="reload">
>
>
>
> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
> wrote:
>
> Brad, if I understand your approach too that would lead to not being able
> to dynamically change common properties in a single config place during
> runtime, as the fill made by maven would be only done once at build time
> right? But at runtime I would need to that as David mention, still n times
> right?
>
> as a use case for instance, with blueprint:cm update-strategy configured
> as 'reload' in combination with felix-fileinstall as directory watcher,
> bundles are reloaded automatically so that when I modify at anytime during
> runtime a property e.g with just a text editor the bundle is initiated
> again with the new property values which is a quite nice feature
>
> best
>
> Pablo
>
>
>
> On 12/07/2016 12:31 AM, David Jencks wrote:
>
> I’d like to make sure I understand what you are doing here…. IIUC during
> the build of your project you are generating multiple configuration files
> with the same or similar content, and each of these is loaded into a
> configuration which is bound to a particular bundle location? So, at build
> time you can change all the duplicate properties at once but if you need to
> change them later you have to alter n (== number of duplicate configs)
> independently? Whereas if you had multi-location support (and possibly
> multi-pid support such as DS provides) you could share a single
> Configuration and change the property while the framework was running in
> one place?
>
>
>
> thanks
>
> david jencks
>
>
>
> On Jul 11, 2016, at 1:42 PM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
>
>
> Pablo,
>
>
>
> One possible solution to this problem that I'm currently looking at is
> using a configuration bundle along with my features bundle. In the
> configuration bundle I have all the cfg files and use properties
> placeholders ${value} to set the value for key/value.
>
>
>
> In the POM I load properties files using the Maven properties plugin and
> that lets me set a global set of properties values that can be used in
> filling in the cfg values. So if a port or URI is shared across a large
> number of them that automatically gets filled in. The features file can
> then specify the cfg files to install and what name to install them with.
>
>
>
> This gets rid of a lot of tedium and by using profiles I should be able to
> switch dev, test and production, and have the properties automatically set
> correctly.
>
>
>
> I'd like to modify this a bit so that dev, test and product cfg files are
> all created simultaneously and simply installed in different directories
> inside the configuration bundle. Then by using different features installs
> I can easily switch between the different configurations without having to
> tediously edit each configuration file.
>
>
>
> Brad
>
>
>
> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> Does Camel/Fuse even support DS? I haven't found any documentation saying
> otherwise. I've only found camel-scr which uses Felix-specific annotations
> and not DS.
>
>
>
> On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com>
> wrote:
>
> David,
>
>
>
> That is some pretty extreme and wild speculation alright. How does one
> use blueprint to not use OSGi appropriately? In the 5 years I've been
> consulting with Fuse/Karaf/OSGi and going to various clients not one of
> them used or uses DS. Not one. They all use bundles, services, and Camel
> with blueprint. The last time I worked with DS I didn't find it provided
> any serious advantage and added another layer that I'd have to teach my
> clients. Not that I wouldn't consider it or use it if I found a real
> advantage but I haven't.
>
>
>
> Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi 4.x
> land much less 5 or 6.
>
>
>
> So for Camel are you using the Java DSL?
>
>
>
> Brad
>
>
>
> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <da...@yahoo.com>
> wrote:
>
> I don’t think karaf is at osgi R4.2 any more, I suggest you look at the
> osgi R5 or R6 config admin spec for “multi location”.
>
>
>
> You guys might be using blueprint every day, but there is no OSGI spec
> work to keep it up to date or even specify obviously necessary features
> such as config admin integration. If blueprint is so great why aren’t the
> proponents keeping the spec related to current OSGI? This is a part of my,
> admittedly extreme, theory that use of blueprint is related to not wanting
> to make the app actually use osgi appropriately.
>
>
>
> And, the project I work on every day uses DS exclusively and still finds
> plenty of ways to abuse osgi in all sorts of inventive ways :-)
>
>
>
> david jencks
>
>
>
>
>
> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com> wrote:
>
>
>
> It is in here;
> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>
>
>
> A bundle is in aries bound to the pid. So it is actually working as
> expected, bit of
>
> a hassle since spring-dm allowed it.
>
>
>
> And yes selling DS into “regular" organizations is about as easy as
> selling snow in Alaska.
>
>
>
> /je
>
>
>
> On Jul 7, 2016, at 12:00 PM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
>
>
> David,
>
>
>
> You live in a very different world than I do. In all the consulting I do
> with Fuse/karaf blueprint is used almost exclusively. I understand DS and
> its uses but also its limits and overhead. It's like telling me one should
> only use Camel Java DSL. That may be one's perspective but that isn't
> everyone's.
>
>
>
> Brad
>
>
>
> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <da...@yahoo.com>
> wrote:
>
> IMNSHO blueprint is only really plausible if you have a large amount of
> Spring based code and you need to convert it to be sort of osgi-compatible
> really quickly without understanding osgi or the code. Otherwise taking
> the time to understand DS and use it is much more satisfactory. DS
> provides this configuration override ability with support for multiple
> pids, although only one of the pids can turn out to be a factory
> configuration. There’s no obvious way of correlating factory
> configurations, so this restriction makes some sense.
>
>
>
> I don’t think there really are any blueprint folks. The cm stuff, while
> obviously required to make the spec remotely plausible, hasn’t made it into
> the spec in the many many years it’s been sitting around.
>
>
>
> david jencks
>
>
>
> On Jul 7, 2016, at 10:41 AM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
>
>
> If I were to sit down with the blueprint folks today to create a wish list
> one thing I'd like to see is for an ability to have a configuration
> hierarchy specified with parent/child relationships much like one has in
> Maven. Have a base configuration file and be able to have another cfg file
> specify that one as its parent. Override properties or add them to the
> child. When the configuration admin fires up it would read up the chain
> and construct the properties.
>
>
>
> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
> brad.johnson@mediadriver.com> wrote:
>
> Ray,
>
>
>
> If I understand your question right the answer is the Aries extension is
> referencing configuration. In karaf/fuse for example the following:
>
>
>
> <cm:property-placeholder persistent-id="com.my.foo"
> update-strategy="reload">
>
>
>
> will load properties from etc/com.my.foo.cfg
>
>
>
> Installing that file is done either manually or by use of a features file.
>
>
>
> Whenever I've attempted to use the PID in more than one bundle it has
> failed and I don't think it is permitted. That's a problem I think and
> something that should be fixed through some other configuration management
> mechanism. Making microservices that might share common properties, for
> example, becomes problematic in that regard and I've resorted to using my
> own OSGi services to overcome that problem.
>
>
>
> Brad
>
>
>
> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <ra...@liferay.com>
> wrote:
>
> Ok, so after a brief review the cm schema is an Aries extension and it
> doesn't appear to support the location binding.
>
> However, it's unclear to me whether this extension is creating the
> configuration or merely referencing one from outside.
>
> Any Aries gurus can answer that?
>
> - Ray
>
>
>
> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <da...@yahoo.com>
> wrote:
>
> I’m not really familiar with blueprint cm but I’d expect that to indicate
> which pid to use to fetch the config from config admin and in the ... how
> to map configuration propertiething blueprint substitution knows about. Is
> that really instructions to create a new configuration and populate it with
> data (what a management agent does)?
>
>
>
> david jencks
>
>
>
> On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com> wrote:
>
>
>
> David, I agree with everything you've said, however this looks like
> blueprint being the agent here:
>
> <cm:property-placeholder persistent-id="my.id" update-strategy="reload">
> ...
> </cm:property-placeholder>
>
> - Ray
>
>
>
> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <da...@yahoo.com>
> wrote:
>
> No, blueprint cm shouldn’t really know about the multi-location. The
> management agent that is creating the configuration should be setting the
> bundle location to the multi-location ”?”.
>
>
>
> david jencks
>
>
>
> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
> wrote:
>
>
>
> I see and would it possible to configure which method is invoked from
> Blueprint?
>
> This is how I do it:
>
> <cm:property-placeholder persistent-id="my.id" update-strategy="reload">
> ...
> </cm:property-placeholder>
>
> is there perhaps some blueprint property where I can tune the second
> argument in the createFactoryConfiguration?
>
> Because it looks like the fact of using config admin through blueprint
> binds the PID to the first bundle using it
>
>
> best
> Pablo
>
> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>
> As long as configurations are not bound to a bundle they can be used by
> any bundle.
>
> The exception clearly shows that the configuration is bound to a bundle.
>
> Creating an unbound configuration requires passing a "?" as the second
> arguments to getConfiguration/createFactoryConfiguration methods of CM.
>
> HTH,
>
> - Ray
>
>
>
> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
> brad.johnson@mediadriver.com> wrote:
>
> I don't think that's possible.
>
>
>
> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
> wrote:
>
> Hello All,
>
> Is it possible to use same config file from multiple bundles
> while using Config Admin with blueprint Blueprint? Because, I can't manage
> to do that, I get the following error:
>
> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm.ManagedService,
> id=214, bundle=86/initial@reference:file:../plugin-1/]: No visibility to
> configuration bound to initial@reference:file:../plugin-2/
>
>
> I saw in this jira a bug opened:
> https://issues.jboss.org/browse/ENTESB-3959
>
>
> However, I fear that this is a problem in the aries blueprint
> implementation as I'm not using KARAF nor FUSE, just a plain osgi
> container. Either that or I'm missing some blueprint configuration. I'm
> basically using blueprint:cm
>
>
> As a workaround I can make a config file per bundle that needs it....
>
> As follows the versions and bundles that I'm using related to the
> container (Running on top of Equinox 3.11):
>
> ID|State |Level|Name
> 5|Active | 2|Apache Aries Whiteboard support for JMX
> DynamicMBean services (1.1.5)|1.1.5
> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
> 13|Active | 3|Aries Remote Service Admin Topology Manager
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment
> Bundle (1.0.0)|1.0.0
> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
> 67|Active | 3|Aries Remote Service Admin Service Provider
> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes
> (1.0.0)|1.0.0
> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
> 94|Active | 3|Aries Remote Service Admin Discovery Config
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 97|Active | 3|Aries Remote Service Admin provider TCP
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
> 130|Active | 2|Apache Aries Blueprint Annotation Impl
> (1.0.1)|1.0.1
> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 134|Active | 3|Aries Remote Service Admin Discovery Local
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 138|Active | 3|Aries Remote Service Admin Core
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
> (1.0.8)|1.0.8
> 147|Active | 2|Aries JPA Container blueprint integration for
> Aries blueprint (1.0.4)|1.0.4
>
> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
> 148|Active | 4|Apache Felix Configuration Admin Service
> (1.8.8)|1.8.8
>
> 0|Active | 0|OSGi System Bundle
> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>
>
> --
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email. E-mail transmission cannot be guaranteed to be
> secure or error-free as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The sender
> therefore does not accept liability for any errors or omissions in the
> contents of this message, which arise as a result of e-mail transmission.
>
> Warning: Although the company has taken reasonable precautions to ensure
> no viruses are present in this email, the company cannot accept
> responsibility for any loss or damage arising from the use of this email or
> attachments.
>
>
>
>
>
>
> --
>
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
>
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
> (@Liferay)
>
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
> (@OSGiAlliance)
>
>
>
>
>
>
>
>
> --
>
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
>
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
> (@Liferay)
>
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
> (@OSGiAlliance)
>
>
>
>
>
>
> --
>
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
>
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
> (@Liferay)
>
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
> (@OSGiAlliance)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Matt Sicker <bo...@gmail.com>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> ------------------------
> Guillaume Nodet
> ------------------------
>
> Red Hat, Open Source Integration
>
>
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
RE: blueprint:cm multiple bundle but same config file
Posted by CLEMENT Jean-Philippe <je...@fr.thalesgroup.com>.
Hi Guillaume,
Your “I've recently added a bunch of important features related to spring in blueprint” sounds promising. Are there some documentation of those new features?
Regards,
JP
De : Guillaume Nodet [mailto:gnodet@apache.org]
Envoyé : mardi 12 juillet 2016 17:58
À : user@aries.apache.org
Objet : Re: blueprint:cm multiple bundle but same config file
I can happily review a patch if you're fancy writing one...
And I disagree with the 'blueprint is dead and nobody cares about it anymore'. What's dead is the blueprint osgi specification for blueprint, not the Aries Blueprint project. I've recently added a bunch of important features related to spring in blueprint.
DS also has some drawbacks as it's not extensible at all : this is leading the OSGi Alliance to write a new spec for transaction support !!!
I think the CDI+DS extension I've been working on those past weeks could bring the best of both world : strong DS semantics for the OSGi bits, but extensibility and support for proxies provided by CDI ;-)
2016-07-12 17:24 GMT+02:00 Brad Johnson <br...@mediadriver.com>>:
David,
I'm all for multilocation support in blueprint. Can't wait for it. But it sounds like your saying blueprint is dead and nobody cares about it anymore so it doesn't seem likely to happen anytime soon. It certainly wouldn't be relevant to Fuse which uses R4 in any case.
On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <br...@mediadriver.com>> wrote:
The features file can have statements like this:
<configfile finalname="/etc/com.foo.cfg" override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
<configfile finalname="/etc/com.bar.cfg" override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
....etc....
That's off the top of my head so take it with a grain of salt for syntax.
When you run the features install it will overwrite the files in the etc directory with the ones in the maven bundle which have now been updated. So instead of modifying configuration files in the etc directory you modifying them in your Maven configuration project and recompile the bundle and then pull it from the repo
in order to update the values.
But you can still modify them in the etc if you wanted. You just have to make sure you have the cm properties set to reload.
<cm:property-placeholder persistent-id="com.foo" update-strategy="reload">
On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <pa...@faw.jku.at>> wrote:
Brad, if I understand your approach too that would lead to not being able to dynamically change common properties in a single config place during runtime, as the fill made by maven would be only done once at build time right? But at runtime I would need to that as David mention, still n times right?
as a use case for instance, with blueprint:cm update-strategy configured as 'reload' in combination with felix-fileinstall as directory watcher, bundles are reloaded automatically so that when I modify at anytime during runtime a property e.g with just a text editor the bundle is initiated again with the new property values which is a quite nice feature
best
Pablo
On 12/07/2016 12:31 AM, David Jencks wrote:
I’d like to make sure I understand what you are doing here…. IIUC during the build of your project you are generating multiple configuration files with the same or similar content, and each of these is loaded into a configuration which is bound to a particular bundle location? So, at build time you can change all the duplicate properties at once but if you need to change them later you have to alter n (== number of duplicate configs) independently? Whereas if you had multi-location support (and possibly multi-pid support such as DS provides) you could share a single Configuration and change the property while the framework was running in one place?
thanks
david jencks
On Jul 11, 2016, at 1:42 PM, Brad Johnson <br...@mediadriver.com>> wrote:
Pablo,
One possible solution to this problem that I'm currently looking at is using a configuration bundle along with my features bundle. In the configuration bundle I have all the cfg files and use properties placeholders ${value} to set the value for key/value.
In the POM I load properties files using the Maven properties plugin and that lets me set a global set of properties values that can be used in filling in the cfg values. So if a port or URI is shared across a large number of them that automatically gets filled in. The features file can then specify the cfg files to install and what name to install them with.
This gets rid of a lot of tedium and by using profiles I should be able to switch dev, test and production, and have the properties automatically set correctly.
I'd like to modify this a bit so that dev, test and product cfg files are all created simultaneously and simply installed in different directories inside the configuration bundle. Then by using different features installs I can easily switch between the different configurations without having to tediously edit each configuration file.
Brad
On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com>> wrote:
Does Camel/Fuse even support DS? I haven't found any documentation saying otherwise. I've only found camel-scr which uses Felix-specific annotations and not DS.
On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com>> wrote:
David,
That is some pretty extreme and wild speculation alright. How does one use blueprint to not use OSGi appropriately? In the 5 years I've been consulting with Fuse/Karaf/OSGi and going to various clients not one of them used or uses DS. Not one. They all use bundles, services, and Camel with blueprint. The last time I worked with DS I didn't find it provided any serious advantage and added another layer that I'd have to teach my clients. Not that I wouldn't consider it or use it if I found a real advantage but I haven't.
Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi 4.x land much less 5 or 6.
So for Camel are you using the Java DSL?
Brad
On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <da...@yahoo.com>> wrote:
I don’t think karaf is at osgi R4.2 any more, I suggest you look at the osgi R5 or R6 config admin spec for “multi location”.
You guys might be using blueprint every day, but there is no OSGI spec work to keep it up to date or even specify obviously necessary features such as config admin integration. If blueprint is so great why aren’t the proponents keeping the spec related to current OSGI? This is a part of my, admittedly extreme, theory that use of blueprint is related to not wanting to make the app actually use osgi appropriately.
And, the project I work on every day uses DS exclusively and still finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
david jencks
On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com>> wrote:
It is in here; https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
A bundle is in aries bound to the pid. So it is actually working as expected, bit of
a hassle since spring-dm allowed it.
And yes selling DS into “regular" organizations is about as easy as selling snow in Alaska.
/je
On Jul 7, 2016, at 12:00 PM, Brad Johnson <br...@mediadriver.com>> wrote:
David,
You live in a very different world than I do. In all the consulting I do with Fuse/karaf blueprint is used almost exclusively. I understand DS and its uses but also its limits and overhead. It's like telling me one should only use Camel Java DSL. That may be one's perspective but that isn't everyone's.
Brad
On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <da...@yahoo.com>> wrote:
IMNSHO blueprint is only really plausible if you have a large amount of Spring based code and you need to convert it to be sort of osgi-compatible really quickly without understanding osgi or the code. Otherwise taking the time to understand DS and use it is much more satisfactory. DS provides this configuration override ability with support for multiple pids, although only one of the pids can turn out to be a factory configuration. There’s no obvious way of correlating factory configurations, so this restriction makes some sense.
I don’t think there really are any blueprint folks. The cm stuff, while obviously required to make the spec remotely plausible, hasn’t made it into the spec in the many many years it’s been sitting around.
david jencks
On Jul 7, 2016, at 10:41 AM, Brad Johnson <br...@mediadriver.com>> wrote:
If I were to sit down with the blueprint folks today to create a wish list one thing I'd like to see is for an ability to have a configuration hierarchy specified with parent/child relationships much like one has in Maven. Have a base configuration file and be able to have another cfg file specify that one as its parent. Override properties or add them to the child. When the configuration admin fires up it would read up the chain and construct the properties.
On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <br...@mediadriver.com>> wrote:
Ray,
If I understand your question right the answer is the Aries extension is referencing configuration. In karaf/fuse for example the following:
<cm:property-placeholder persistent-id="com.my.foo" update-strategy="reload">
will load properties from etc/com.my.foo.cfg
Installing that file is done either manually or by use of a features file.
Whenever I've attempted to use the PID in more than one bundle it has failed and I don't think it is permitted. That's a problem I think and something that should be fixed through some other configuration management mechanism. Making microservices that might share common properties, for example, becomes problematic in that regard and I've resorted to using my own OSGi services to overcome that problem.
Brad
On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <ra...@liferay.com>> wrote:
Ok, so after a brief review the cm schema is an Aries extension and it doesn't appear to support the location binding.
However, it's unclear to me whether this extension is creating the configuration or merely referencing one from outside.
Any Aries gurus can answer that?
- Ray
On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <da...@yahoo.com>> wrote:
I’m not really familiar with blueprint cm but I’d expect that to indicate which pid to use to fetch the config from config admin and in the ... how to map configuration propertiething blueprint substitution knows about. Is that really instructions to create a new configuration and populate it with data (what a management agent does)?
david jencks
On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com>> wrote:
David, I agree with everything you've said, however this looks like blueprint being the agent here:
<cm:property-placeholder persistent-id="my.id<http://my.id/>" update-strategy="reload">
...
</cm:property-placeholder>
- Ray
On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <da...@yahoo.com>> wrote:
No, blueprint cm shouldn’t really know about the multi-location. The management agent that is creating the configuration should be setting the bundle location to the multi-location ”?”.
david jencks
On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at>> wrote:
I see and would it possible to configure which method is invoked from Blueprint?
This is how I do it:
<cm:property-placeholder persistent-id="my.id<http://my.id/>" update-strategy="reload">
...
</cm:property-placeholder>
is there perhaps some blueprint property where I can tune the second argument in the createFactoryConfiguration?
Because it looks like the fact of using config admin through blueprint binds the PID to the first bundle using it
best
Pablo
On 07/07/2016 4:41 PM, Raymond Auge wrote:
As long as configurations are not bound to a bundle they can be used by any bundle.
The exception clearly shows that the configuration is bound to a bundle.
Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
HTH,
- Ray
On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <br...@mediadriver.com>> wrote:
I don't think that's possible.
On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pa...@faw.jku.at>> wrote:
Hello All,
Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm<http://org.osgi.service.cm/>.ManagedService, id=214, bundle=86/initial@reference:file:../plugin-1/<mailto:bundle=86/initial@reference:file:../plugin-1/>]: No visibility to configuration bound to initial@reference:file:../plugin-2/<mailto:initial@reference:file:../plugin-2/>
I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959
However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
As a workaround I can make a config file per bundle that needs it....
As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
ID|State |Level|Name
5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
--
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
--
Raymond Augé<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect Liferay, Inc.<http://www.liferay.com/> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance<http://osgi.org/> (@OSGiAlliance)
--
Raymond Augé<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect Liferay, Inc.<http://www.liferay.com/> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance<http://osgi.org/> (@OSGiAlliance)
--
Raymond Augé<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect Liferay, Inc.<http://www.liferay.com/> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance<http://osgi.org/> (@OSGiAlliance)
--
Matt Sicker <bo...@gmail.com>>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
Interestingly last night I started working with the CDI and delta spike
implementations and some of the pax-cdi stuff. Somehow that feels right to
me. Obviously that's a different issue than Blueprint/SCR but with Camel
I'm using endpoints for much of the communication between bundles so the
underlying mechanics of services is less important. While I use OSGi
services/interfaces with blueprint and Camel they aren't critical to me. I
can just as easily use endpoints for inter-bundle communication.
But the wiring and injection that pax-cdi brings and the ease of testing
(especially compared to CamelBlueprintTestSupport) is amazing. I haven't
tried a blend of SCR and CDI and I'm not sure how well that would work. I
think if it was done right it would be SCR managing the outward facing
concerns of the bundle and CDI used to wire up the Camel internals.
On Tue, Aug 2, 2016 at 2:55 AM, Timothy Ward <ti...@apache.org>
wrote:
> This sounds like a good place to use the whiteboard pattern and marker
> properties. Using annotations requires a number of extra steps from the
> Camel/OSGi runtime, where a service property would just require a simple
> filter on the service registry lookup.
>
> Regards,
>
> Tim
>
> On 2 Aug 2016, at 02:44, Matt Sicker <bo...@gmail.com> wrote:
>
> Can you include scanning services or certain types of annotated services
> to inject camel things into? That way you can use DS components more easily.
>
> On 1 August 2016 at 20:03, Brad Johnson <br...@mediadriver.com>
> wrote:
>
>> The CamelContext disambiguation obviously is a next step...
>>
>> On Mon, Aug 1, 2016 at 8:01 PM, Brad Johnson <
>> brad.johnson@mediadriver.com> wrote:
>>
>>> I'd thought that it was possible since the examples have a
>>> SimpleRegistry and mention using it to register beans. But when I looked
>>> at the AbstractCamelRunner it became obvious that that would not work.
>>>
>>> I'm trying something by creating a new SCRRegistry type just for the
>>> sake of experimentation. Internally it has a CompositeRegistry and the
>>> AbstractCamelRunner which I'm modifying uses the new SCRRegistry which has
>>> a setter or on it for both a SimpleRegistry and an OsgiRegistry. If it
>>> finds the bundle context it creates the OSGi service registry and adds it
>>> and in either case adds a SimpleRegistry after it.
>>>
>>>
>>> protected void createCamelContext(final BundleContext bundleContext,
>>> final Map<String, String> props) {
>>> if (bundleContext != null) {
>>> OsgiServiceRegistry osgiRegistry = new
>>> OsgiServiceRegistry(bundleContext);
>>> context = new OsgiDefaultCamelContext(bundleContext,
>>> osgiRegistry);
>>> // Setup the application context classloader with the bundle
>>> classloader
>>> context.setApplicationContextClassLoader(new
>>> BundleDelegatingClassLoader(bundleContext.getBundle()));
>>> // and make sure the TCCL is our classloader
>>>
>>> Thread.currentThread().setContextClassLoader(context.getApplicationContextClassLoader());
>>> this.registry.setOsgiRegistry(osgiRegistry);
>>> }
>>> registry.setSimpleRegistry(new SimpleRegistry());
>>> context = new DefaultCamelContext(registry);
>>>
>>>
>>>
>>> Inside the SCRRegistry it delegates all its Registry interface calls to
>>> the CompositeRegistry but it keeps a handle on the SimpleRegistry. So to
>>> register a class one can do the following:
>>>
>>> registry.register(POValidator.class);
>>>
>>> In this case it's very simple instantiation of the no-arg constructor
>>> and then looking for EndpointInject annotations and setting it to the
>>> ProducerTemplate and the URI it finds. This is such a quick and naive cut
>>> that I'm not even checking to see if there's an endpoint by that name in
>>> the registry already which I could just use instead. Obviously if I do
>>> anything more with this I'll look at reusing the existing libraries for
>>> annotation processing instead of writing this stuff by hand. I still
>>> haven't tested this by throwing it in karaf with Felix or any other OSGi
>>> implementation.
>>>
>>> public void register(Class clazz){
>>> try {
>>> Object o=clazz.newInstance();
>>> for(Field declaredField:clazz.getDeclaredFields())
>>> {
>>> for(EndpointInject endpoint:
>>> declaredField.getAnnotationsByType(EndpointInject.class))
>>> {
>>> declaredField.setAccessible(true);
>>> ProducerTemplate template = camelContext.createProducerTemplate();
>>> template.setDefaultEndpointUri(endpoint.uri());
>>> declaredField.set(o,template);
>>> }
>>> }
>>> this.simpleRegistry.put(clazz.getSimpleName(), o);
>>> } catch (InstantiationException | IllegalAccessException e) {
>>> //TODO log..
>>> }
>>> }
>>>
>>> On Mon, Aug 1, 2016 at 6:33 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> Can you even make a semi-private service in DS/SCR? What could the
>>>> equivalent be to a blueprint bean that isn't exported as a service? Or is
>>>> the philosophy to make all services public in DS?
>>>>
>>>> On 1 August 2016 at 18:12, Brad Johnson <br...@mediadriver.com>
>>>> wrote:
>>>>
>>>>> Tim,
>>>>>
>>>>> After working with DS and SCR a little I can understand its benefits.
>>>>> One obvious advantage was being able to write basic JUnit tests to test my
>>>>> routes without having to fire up CBTS. I've always disliked working in XML
>>>>> so it is odd being in the position like I sound like I'm the one
>>>>> championing it.
>>>>>
>>>>> The main problem right now with Camel is that while SCR handles all
>>>>> the external items there isn't a way to do any injection of "local"
>>>>> dependencies. By that I mean within my own bundle I might have validators,
>>>>> handlers, local data models, etc. that I want to stand up and run in my
>>>>> Camel routes. Camel SCR doesn't have a mechanism for doing that.
>>>>>
>>>>> When one runs it locally in the IDE it fires up a SimpleRegistry and
>>>>> uses that to register everything and in that case you can manually add your
>>>>> own beans before setting up route definitions. If the bundle is running
>>>>> where it has a bundle context it instead fires up an
>>>>> OsgiServiceRegistry(don't recall the full name.) In that case you can't add
>>>>> your local beans.
>>>>>
>>>>> I noted that there is a CompositeRegistry in the AbstractCamelRunner
>>>>> and perhaps that should always be the one used. If one boots up and an
>>>>> OSGi service registry is created both it and the SimpleRegistry are added
>>>>> to the CompositeRegistry but one can access the SimpleRegistry in order to
>>>>> add one's local dependencies for Camel routes.
>>>>>
>>>>> On Wed, Jul 13, 2016 at 3:34 AM, Timothy Ward <timothyjward@apache.org
>>>>> > wrote:
>>>>>
>>>>>> Hi Brad,
>>>>>>
>>>>>> I’ve been watching this thread for a while, and you’ve finally
>>>>>> managed to draw me in :)
>>>>>>
>>>>>>
>>>>>> On 12 Jul 2016, at 17:42, Brad Johnson <br...@mediadriver.com>
>>>>>> wrote:
>>>>>>
>>>>>> Guillaume,
>>>>>>
>>>>>> I'm still using Blueprint and have found Camel/SCR to be a pain to
>>>>>> work with. It provides no tangible benefit if one is using Blueprint for
>>>>>> routes and dependency injection anyway as it simply introduces one more way
>>>>>> of configuring things. It was interesting to read the other day that
>>>>>> Christian seems to have the same impression of the complexity of SCR. I
>>>>>> remember when I first tried I thought it looked pretty cool but started
>>>>>> running into problems.
>>>>>>
>>>>>>
>>>>>> So what you’re comparing here isn’t really apples with apples. A long
>>>>>> way back Camel provided a bunch of Spring XML sugar to make configuring
>>>>>> Camel simpler. This was obviously a good thing because setting up Camel was
>>>>>> (and is) hard. To this day people still use the Spring syntax for building
>>>>>> their Camel routes. OSGi blueprint was effectively a move by Spring to
>>>>>> standardise the Spring DM container, and so unsurprisingly blueprint looks
>>>>>> a lot like Spring. Some people did the work to port the Camel Spring
>>>>>> configuration to OSGi blueprint, and that’s why Camel is easy to use in
>>>>>> blueprint.
>>>>>>
>>>>>> If someone actually spent some time putting together a nice
>>>>>> integration with SCR then I’m sure that using SCR would be at least as easy
>>>>>> as blueprint. The problem here is that relatively few SCR developers/users
>>>>>> use Camel, and the ones that do are just told to “use blueprint”.
>>>>>>
>>>>>> That DS is in its second generation and only now getting around to
>>>>>> transactions is telling. Either it has reached its natural boundaries and
>>>>>> is now over-reaching or wasn’t full thought out.
>>>>>>
>>>>>>
>>>>>> DS is actually working on its fifth release, and transactions are
>>>>>> nowhere to be seen. You may be referring to the Transaction Control
>>>>>> specification, which is separate from DS. They can be used together very
>>>>>> effectively, but you could equally use Transaction Control with blueprint.
>>>>>>
>>>>>> DS is actually one of the “good citizens” of the DI world in that it
>>>>>> deliberately does less in order to do it well. There’s no dependency
>>>>>> proxying, no aspects, just the code that you wrote injected with some other
>>>>>> code that someone wrote.
>>>>>>
>>>>>> To me it's a component and service bootstrapping mechanism which
>>>>>> represents a small portion of the world I work in - transforms, routing,
>>>>>> EIPs, etc. I've no reason to embrace it or deny it unless it either makes
>>>>>> my job much easier or I can't live without it. So far adding Camel SCR and
>>>>>> DS into the middleware just results in one more thing I have to deal with.
>>>>>>
>>>>>>
>>>>>> This is a perfectly acceptable viewpoint. If the fundamental
>>>>>> limitations of the blueprint model aren’t a problem for you then switching
>>>>>> right now is almost certainly unnecessary.
>>>>>>
>>>>>>
>>>>>> I think Blueprint works well these days and has come a long way in
>>>>>> the past 3 years. The Aries team is to be commended for some great work.
>>>>>>
>>>>>>
>>>>>> Aries Blueprint has had a lot of extensions and improvements over the
>>>>>> last three years. Sadly the same cannot be said for the specifications or
>>>>>> other implementations. Aries Blueprint is very much the last implementation
>>>>>> standing, and there has been no effort to standardise the new features (or
>>>>>> even to try fixing the problems with the original standard). The set of
>>>>>> RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance is
>>>>>> very telling.
>>>>>>
>>>>>> As far as Aries blueprint is concerned, the main reason that it is
>>>>>> still alive seems to be the fact that it was included in Karaf, and that
>>>>>> Karaf provides Camel integration alongside it. Even Karaf itself is
>>>>>> starting to move to use DS internally, offering blueprint as something for
>>>>>> applications to use.
>>>>>>
>>>>>>
>>>>>> I’ve been surprised by the near religious zeal of some of the DS
>>>>>> advocates.
>>>>>>
>>>>>>
>>>>>> Most OSGi developers I know (myself included) who really start to use
>>>>>> DS consider it to be roughly equivalent to magic. The fact that the model
>>>>>> can be as simple as it is and yet still flexible, correct and safe is both
>>>>>> surprising and pleasing. Moving back to “not DS” is usually pretty painful
>>>>>> and reminds people why they love DS so much.
>>>>>>
>>>>>> I'll be interested in seeing the DS semantics and proxies for CDI.
>>>>>> Heh. Proxies are another technology that I don't care about one way or the
>>>>>> other as long as things work well and don't require a lot of
>>>>>> configuration. So it’s great if we can get rid of proxies but not so great
>>>>>> if I now have to trade that off for configuration of start up order on
>>>>>> services to make sure everything is running before Camel routes come up.
>>>>>>
>>>>>>
>>>>>> Actually, this is one of the places where DS really shines. If you
>>>>>> write a DS component properly (i.e. without trying to dig out of the DS
>>>>>> lifecycle) then startup ordering ceases to be an issue.
>>>>>>
>>>>>> Again, someone with a little time and expertise would probably find
>>>>>> that Camel + DS can be a really effective solution. The problem is finding
>>>>>> the person who has the time, expertise and inclination…
>>>>>>
>>>>>> Tim Ward
>>>>>>
>>>>>> Apache Aries PMC Member,
>>>>>> OSGi IoT Expert Group Chair,
>>>>>> Author Enterprise OSGi in Action
>>>>>> timothyjward@apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gn...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> I can happily review a patch if you're fancy writing one...
>>>>>>>
>>>>>>> And I disagree with the 'blueprint is dead and nobody cares about it
>>>>>>> anymore'. What's dead is the blueprint osgi specification for blueprint,
>>>>>>> not the Aries Blueprint project. I've recently added a bunch of important
>>>>>>> features related to spring in blueprint.
>>>>>>>
>>>>>>> DS also has some drawbacks as it's not extensible at all : this is
>>>>>>> leading the OSGi Alliance to write a new spec for transaction support !!!
>>>>>>>
>>>>>>> I think the CDI+DS extension I've been working on those past weeks
>>>>>>> could bring the best of both world : strong DS semantics for the OSGi bits,
>>>>>>> but extensibility and support for proxies provided by CDI ;-)
>>>>>>>
>>>>>>>
>>>>>>> 2016-07-12 17:24 GMT+02:00 Brad Johnson <
>>>>>>> brad.johnson@mediadriver.com>:
>>>>>>>
>>>>>>>> David,
>>>>>>>>
>>>>>>>> I'm all for multilocation support in blueprint. Can't wait for it.
>>>>>>>> But it sounds like your saying blueprint is dead and nobody cares about
>>>>>>>> it anymore so it doesn't seem likely to happen anytime soon. It certainly
>>>>>>>> wouldn't be relevant to Fuse which uses R4 in any case.
>>>>>>>>
>>>>>>>> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <
>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>
>>>>>>>>> The features file can have statements like this:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <configfile finalname="/etc/com.foo.cfg"
>>>>>>>>> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
>>>>>>>>> <configfile finalname="/etc/com.bar.cfg"
>>>>>>>>> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
>>>>>>>>> ....etc....
>>>>>>>>> That's off the top of my head so take it with a grain of salt for
>>>>>>>>> syntax.
>>>>>>>>>
>>>>>>>>> When you run the features install it will overwrite the files in
>>>>>>>>> the etc directory with the ones in the maven bundle which have now been
>>>>>>>>> updated. So instead of modifying configuration files in the etc directory
>>>>>>>>> you modifying them in your Maven configuration project and recompile the
>>>>>>>>> bundle and then pull it from the repo
>>>>>>>>> in order to update the values.
>>>>>>>>>
>>>>>>>>> But you can still modify them in the etc if you wanted. You just
>>>>>>>>> have to make sure you have the cm properties set to reload.
>>>>>>>>>
>>>>>>>>> <cm:property-placeholder persistent-id="com.foo"
>>>>>>>>> update-strategy="reload">
>>>>>>>>>
>>>>>>>>> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <
>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>
>>>>>>>>>> Brad, if I understand your approach too that would lead to not
>>>>>>>>>> being able to dynamically change common properties in a single config place
>>>>>>>>>> during runtime, as the fill made by maven would be only done once at build
>>>>>>>>>> time right? But at runtime I would need to that as David mention, still n
>>>>>>>>>> times right?
>>>>>>>>>>
>>>>>>>>>> as a use case for instance, with blueprint:cm update-strategy
>>>>>>>>>> configured as 'reload' in combination with felix-fileinstall as directory
>>>>>>>>>> watcher, bundles are reloaded automatically so that when I modify at
>>>>>>>>>> anytime during runtime a property e.g with just a text editor the bundle is
>>>>>>>>>> initiated again with the new property values which is a quite nice feature
>>>>>>>>>>
>>>>>>>>>> best
>>>>>>>>>>
>>>>>>>>>> Pablo
>>>>>>>>>>
>>>>>>>>>> On 12/07/2016 12:31 AM, David Jencks wrote:
>>>>>>>>>>
>>>>>>>>>> I’d like to make sure I understand what you are doing here….
>>>>>>>>>> IIUC during the build of your project you are generating multiple
>>>>>>>>>> configuration files with the same or similar content, and each of these is
>>>>>>>>>> loaded into a configuration which is bound to a particular bundle
>>>>>>>>>> location? So, at build time you can change all the duplicate properties at
>>>>>>>>>> once but if you need to change them later you have to alter n (== number of
>>>>>>>>>> duplicate configs) independently? Whereas if you had multi-location
>>>>>>>>>> support (and possibly multi-pid support such as DS provides) you could
>>>>>>>>>> share a single Configuration and change the property while the framework
>>>>>>>>>> was running in one place?
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <
>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Pablo,
>>>>>>>>>>
>>>>>>>>>> One possible solution to this problem that I'm currently looking
>>>>>>>>>> at is using a configuration bundle along with my features bundle. In the
>>>>>>>>>> configuration bundle I have all the cfg files and use properties
>>>>>>>>>> placeholders ${value} to set the value for key/value.
>>>>>>>>>>
>>>>>>>>>> In the POM I load properties files using the Maven properties
>>>>>>>>>> plugin and that lets me set a global set of properties values that can be
>>>>>>>>>> used in filling in the cfg values. So if a port or URI is shared across a
>>>>>>>>>> large number of them that automatically gets filled in. The features file
>>>>>>>>>> can then specify the cfg files to install and what name to install them
>>>>>>>>>> with.
>>>>>>>>>>
>>>>>>>>>> This gets rid of a lot of tedium and by using profiles I should
>>>>>>>>>> be able to switch dev, test and production, and have the properties
>>>>>>>>>> automatically set correctly.
>>>>>>>>>>
>>>>>>>>>> I'd like to modify this a bit so that dev, test and product cfg
>>>>>>>>>> files are all created simultaneously and simply installed in different
>>>>>>>>>> directories inside the configuration bundle. Then by using different
>>>>>>>>>> features installs I can easily switch between the different configurations
>>>>>>>>>> without having to tediously edit each configuration file.
>>>>>>>>>>
>>>>>>>>>> Brad
>>>>>>>>>>
>>>>>>>>>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Does Camel/Fuse even support DS? I haven't found any
>>>>>>>>>>> documentation saying otherwise. I've only found camel-scr which uses
>>>>>>>>>>> Felix-specific annotations and not DS.
>>>>>>>>>>>
>>>>>>>>>>> On 7 July 2016 at 14:32, Brad Johnson <
>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> David,
>>>>>>>>>>>>
>>>>>>>>>>>> That is some pretty extreme and wild speculation alright. How
>>>>>>>>>>>> does one use blueprint to not use OSGi appropriately? In the 5 years I've
>>>>>>>>>>>> been consulting with Fuse/Karaf/OSGi and going to various clients not one
>>>>>>>>>>>> of them used or uses DS. Not one. They all use bundles, services, and
>>>>>>>>>>>> Camel with blueprint. The last time I worked with DS I didn't find it
>>>>>>>>>>>> provided any serious advantage and added another layer that I'd have to
>>>>>>>>>>>> teach my clients. Not that I wouldn't consider it or use it if I found a
>>>>>>>>>>>> real advantage but I haven't.
>>>>>>>>>>>>
>>>>>>>>>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in
>>>>>>>>>>>> OSGi 4.x land much less 5 or 6.
>>>>>>>>>>>>
>>>>>>>>>>>> So for Camel are you using the Java DSL?
>>>>>>>>>>>>
>>>>>>>>>>>> Brad
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <
>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you
>>>>>>>>>>>>> look at the osgi R5 or R6 config admin spec for “multi location”.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You guys might be using blueprint every day, but there is no
>>>>>>>>>>>>> OSGI spec work to keep it up to date or even specify obviously necessary
>>>>>>>>>>>>> features such as config admin integration. If blueprint is so great why
>>>>>>>>>>>>> aren’t the proponents keeping the spec related to current OSGI? This is a
>>>>>>>>>>>>> part of my, admittedly extreme, theory that use of blueprint is related to
>>>>>>>>>>>>> not wanting to make the app actually use osgi appropriately.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And, the project I work on every day uses DS exclusively and
>>>>>>>>>>>>> still finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is in here;
>>>>>>>>>>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> A bundle is in aries bound to the pid. So it is actually
>>>>>>>>>>>>> working as expected, bit of
>>>>>>>>>>>>> a hassle since spring-dm allowed it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And yes selling DS into “regular" organizations is about as
>>>>>>>>>>>>> easy as selling snow in Alaska.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /je
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <
>>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> David,
>>>>>>>>>>>>>
>>>>>>>>>>>>> You live in a very different world than I do. In all the
>>>>>>>>>>>>> consulting I do with Fuse/karaf blueprint is used almost exclusively. I
>>>>>>>>>>>>> understand DS and its uses but also its limits and overhead. It's like
>>>>>>>>>>>>> telling me one should only use Camel Java DSL. That may be one's
>>>>>>>>>>>>> perspective but that isn't everyone's.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Brad
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <
>>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> IMNSHO blueprint is only really plausible if you have a large
>>>>>>>>>>>>>> amount of Spring based code and you need to convert it to be sort of
>>>>>>>>>>>>>> osgi-compatible really quickly without understanding osgi or the code.
>>>>>>>>>>>>>> Otherwise taking the time to understand DS and use it is much more
>>>>>>>>>>>>>> satisfactory. DS provides this configuration override ability with support
>>>>>>>>>>>>>> for multiple pids, although only one of the pids can turn out to be a
>>>>>>>>>>>>>> factory configuration. There’s no obvious way of correlating factory
>>>>>>>>>>>>>> configurations, so this restriction makes some sense.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don’t think there really are any blueprint folks. The cm
>>>>>>>>>>>>>> stuff, while obviously required to make the spec remotely plausible, hasn’t
>>>>>>>>>>>>>> made it into the spec in the many many years it’s been sitting around.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <
>>>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If I were to sit down with the blueprint folks today to
>>>>>>>>>>>>>> create a wish list one thing I'd like to see is for an ability to have a
>>>>>>>>>>>>>> configuration hierarchy specified with parent/child relationships much like
>>>>>>>>>>>>>> one has in Maven. Have a base configuration file and be able to have
>>>>>>>>>>>>>> another cfg file specify that one as its parent. Override properties or add
>>>>>>>>>>>>>> them to the child. When the configuration admin fires up it would read up
>>>>>>>>>>>>>> the chain and construct the properties.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ray,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If I understand your question right the answer is the Aries
>>>>>>>>>>>>>>> extension is referencing configuration. In karaf/fuse for example the
>>>>>>>>>>>>>>> following:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Installing that file is done either manually or by use of a
>>>>>>>>>>>>>>> features file.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Whenever I've attempted to use the PID in more than one
>>>>>>>>>>>>>>> bundle it has failed and I don't think it is permitted. That's a problem I
>>>>>>>>>>>>>>> think and something that should be fixed through some other configuration
>>>>>>>>>>>>>>> management mechanism. Making microservices that might share common
>>>>>>>>>>>>>>> properties, for example, becomes problematic in that regard and I've
>>>>>>>>>>>>>>> resorted to using my own OSGi services to overcome that problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Brad
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ok, so after a brief review the cm schema is an Aries
>>>>>>>>>>>>>>>> extension and it doesn't appear to support the location binding.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> However, it's unclear to me whether this extension is
>>>>>>>>>>>>>>>> creating the configuration or merely referencing one from outside.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Any Aries gurus can answer that?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <
>>>>>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I’m not really familiar with blueprint cm but I’d expect
>>>>>>>>>>>>>>>>> that to indicate which pid to use to fetch the config from config admin and
>>>>>>>>>>>>>>>>> in the ... how to map configuration propertiething blueprint substitution
>>>>>>>>>>>>>>>>> knows about. Is that really instructions to create a new configuration and
>>>>>>>>>>>>>>>>> populate it with data (what a management agent does)?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <
>>>>>>>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> David, I agree with everything you've said, however this
>>>>>>>>>>>>>>>>> looks like blueprint being the agent here:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No, blueprint cm shouldn’t really know about the
>>>>>>>>>>>>>>>>>> multi-location. The management agent that is creating the configuration
>>>>>>>>>>>>>>>>>> should be setting the bundle location to the multi-location ”?”.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I see and would it possible to configure which method is
>>>>>>>>>>>>>>>>>> invoked from Blueprint?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This is how I do it:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> is there perhaps some blueprint property where I can tune
>>>>>>>>>>>>>>>>>> the second argument in the createFactoryConfiguration?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Because it looks like the fact of using config admin
>>>>>>>>>>>>>>>>>> through blueprint binds the PID to the first bundle using it
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>>>>> Pablo
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As long as configurations are not bound to a bundle they
>>>>>>>>>>>>>>>>>> can be used by any bundle.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The exception clearly shows that the configuration is
>>>>>>>>>>>>>>>>>> bound to a bundle.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Creating an unbound configuration requires passing a "?"
>>>>>>>>>>>>>>>>>> as the second arguments to getConfiguration/createFactoryConfiguration
>>>>>>>>>>>>>>>>>> methods of CM.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> HTH,
>>>>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Is it possible to use same config file from
>>>>>>>>>>>>>>>>>>>> multiple bundles while using Config Admin with blueprint Blueprint?
>>>>>>>>>>>>>>>>>>>> Because, I can't manage to do that, I get the following error:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No
>>>>>>>>>>>>>>>>>>>> visibility to configuration bound to
>>>>>>>>>>>>>>>>>>>> initial@reference:file:../plugin-2/
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> However, I fear that this is a problem in the aries
>>>>>>>>>>>>>>>>>>>> blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>>>>>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>>>>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> As a workaround I can make a config file per bundle
>>>>>>>>>>>>>>>>>>>> that needs it....
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> As follows the versions and bundles that I'm using
>>>>>>>>>>>>>>>>>>>> related to the container (Running on top of Equinox 3.11):
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support
>>>>>>>>>>>>>>>>>>>> for JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core
>>>>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>>> Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>>> 15|Active | 2|Aries JPA Container
>>>>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API
>>>>>>>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>>> Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM
>>>>>>>>>>>>>>>>>>>> (1.0.7)|1.0.7
>>>>>>>>>>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core
>>>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>>>>>> (1.5.0)|1.5.0
>>>>>>>>>>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>>>>>> Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed
>>>>>>>>>>>>>>>>>>>> Contexts (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API
>>>>>>>>>>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>>> Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction
>>>>>>>>>>>>>>>>>>>> Blueprint (1.1.1)|1.1.1
>>>>>>>>>>>>>>>>>>>> 73|Active | 2|Aries JPA Container API
>>>>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for
>>>>>>>>>>>>>>>>>>>> Legacy Runtimes (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction
>>>>>>>>>>>>>>>>>>>> Manager (1.3.0)|1.3.0
>>>>>>>>>>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>>> Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>>> provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint
>>>>>>>>>>>>>>>>>>>> Annotation API (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction
>>>>>>>>>>>>>>>>>>>> Blueprint (2.1.0)|2.1.0
>>>>>>>>>>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API
>>>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint
>>>>>>>>>>>>>>>>>>>> Annotation Impl (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>>> Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>>> Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>>>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service
>>>>>>>>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic
>>>>>>>>>>>>>>>>>>>> Weaving Bundle (1.0.8)|1.0.8
>>>>>>>>>>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint
>>>>>>>>>>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 11|Active | 4|Apache Felix File Install
>>>>>>>>>>>>>>>>>>>> (3.5.4)|3.5.4
>>>>>>>>>>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell
>>>>>>>>>>>>>>>>>>>> (0.12.0)|0.12.0
>>>>>>>>>>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command
>>>>>>>>>>>>>>>>>>>> (0.16.0)|0.16.0
>>>>>>>>>>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator
>>>>>>>>>>>>>>>>>>>> Service (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime
>>>>>>>>>>>>>>>>>>>> (0.16.2)|0.16.2
>>>>>>>>>>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management
>>>>>>>>>>>>>>>>>>>> Console (1.2.8)|1.2.8
>>>>>>>>>>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration
>>>>>>>>>>>>>>>>>>>> Admin Service (1.8.8)|1.8.8
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email.
>>>>>>>>>>>>>>>>>>>> The recipient should check this email and any attachments for the presence
>>>>>>>>>>>>>>>>>>>> of viruses. The company accepts no liability for any damage caused by any
>>>>>>>>>>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>>>>>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>>>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>>>>>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>>>>>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Warning: Although the company has taken reasonable
>>>>>>>>>>>>>>>>>>>> precautions to ensure no viruses are present in this email, the company
>>>>>>>>>>>>>>>>>>>> cannot accept responsibility for any loss or damage arising from the use of
>>>>>>>>>>>>>>>>>>>> this email or attachments.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Red Hat, Open Source Integration
>>>>>>>
>>>>>>> Email: gnodet@redhat.com
>>>>>>> Web: http://fusesource.com
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Timothy Ward <ti...@apache.org>.
This sounds like a good place to use the whiteboard pattern and marker properties. Using annotations requires a number of extra steps from the Camel/OSGi runtime, where a service property would just require a simple filter on the service registry lookup.
Regards,
Tim
On 2 Aug 2016, at 02:44, Matt Sicker <bo...@gmail.com>> wrote:
Can you include scanning services or certain types of annotated services to inject camel things into? That way you can use DS components more easily.
On 1 August 2016 at 20:03, Brad Johnson <br...@mediadriver.com>> wrote:
The CamelContext disambiguation obviously is a next step...
On Mon, Aug 1, 2016 at 8:01 PM, Brad Johnson <br...@mediadriver.com>> wrote:
I'd thought that it was possible since the examples have a SimpleRegistry and mention using it to register beans. But when I looked at the AbstractCamelRunner it became obvious that that would not work.
I'm trying something by creating a new SCRRegistry type just for the sake of experimentation. Internally it has a CompositeRegistry and the AbstractCamelRunner which I'm modifying uses the new SCRRegistry which has a setter or on it for both a SimpleRegistry and an OsgiRegistry. If it finds the bundle context it creates the OSGi service registry and adds it and in either case adds a SimpleRegistry after it.
protected void createCamelContext(final BundleContext bundleContext, final Map<String, String> props) {
if (bundleContext != null) {
OsgiServiceRegistry osgiRegistry = new OsgiServiceRegistry(bundleContext);
context = new OsgiDefaultCamelContext(bundleContext, osgiRegistry);
// Setup the application context classloader with the bundle classloader
context.setApplicationContextClassLoader(new BundleDelegatingClassLoader(bundleContext.getBundle()));
// and make sure the TCCL is our classloader
Thread.currentThread().setContextClassLoader(context.getApplicationContextClassLoader());
this.registry.setOsgiRegistry(osgiRegistry);
}
registry.setSimpleRegistry(new SimpleRegistry());
context = new DefaultCamelContext(registry);
Inside the SCRRegistry it delegates all its Registry interface calls to the CompositeRegistry but it keeps a handle on the SimpleRegistry. So to register a class one can do the following:
registry.register(POValidator.class);
In this case it's very simple instantiation of the no-arg constructor and then looking for EndpointInject annotations and setting it to the ProducerTemplate and the URI it finds. This is such a quick and naive cut that I'm not even checking to see if there's an endpoint by that name in the registry already which I could just use instead. Obviously if I do anything more with this I'll look at reusing the existing libraries for annotation processing instead of writing this stuff by hand. I still haven't tested this by throwing it in karaf with Felix or any other OSGi implementation.
public void register(Class clazz){
try {
Object o=clazz.newInstance();
for(Field declaredField:clazz.getDeclaredFields())
{
for(EndpointInject endpoint: declaredField.getAnnotationsByType(EndpointInject.class))
{
declaredField.setAccessible(true);
ProducerTemplate template = camelContext.createProducerTemplate();
template.setDefaultEndpointUri(endpoint.uri());
declaredField.set(o,template);
}
}
this.simpleRegistry.put(clazz.getSimpleName(), o);
} catch (InstantiationException | IllegalAccessException e) {
//TODO log..
}
}
On Mon, Aug 1, 2016 at 6:33 PM, Matt Sicker <bo...@gmail.com>> wrote:
Can you even make a semi-private service in DS/SCR? What could the equivalent be to a blueprint bean that isn't exported as a service? Or is the philosophy to make all services public in DS?
On 1 August 2016 at 18:12, Brad Johnson <br...@mediadriver.com>> wrote:
Tim,
After working with DS and SCR a little I can understand its benefits. One obvious advantage was being able to write basic JUnit tests to test my routes without having to fire up CBTS. I've always disliked working in XML so it is odd being in the position like I sound like I'm the one championing it.
The main problem right now with Camel is that while SCR handles all the external items there isn't a way to do any injection of "local" dependencies. By that I mean within my own bundle I might have validators, handlers, local data models, etc. that I want to stand up and run in my Camel routes. Camel SCR doesn't have a mechanism for doing that.
When one runs it locally in the IDE it fires up a SimpleRegistry and uses that to register everything and in that case you can manually add your own beans before setting up route definitions. If the bundle is running where it has a bundle context it instead fires up an OsgiServiceRegistry(don't recall the full name.) In that case you can't add your local beans.
I noted that there is a CompositeRegistry in the AbstractCamelRunner and perhaps that should always be the one used. If one boots up and an OSGi service registry is created both it and the SimpleRegistry are added to the CompositeRegistry but one can access the SimpleRegistry in order to add one's local dependencies for Camel routes.
On Wed, Jul 13, 2016 at 3:34 AM, Timothy Ward <ti...@apache.org>> wrote:
Hi Brad,
I’ve been watching this thread for a while, and you’ve finally managed to draw me in :)
On 12 Jul 2016, at 17:42, Brad Johnson <br...@mediadriver.com>> wrote:
Guillaume,
I'm still using Blueprint and have found Camel/SCR to be a pain to work with. It provides no tangible benefit if one is using Blueprint for routes and dependency injection anyway as it simply introduces one more way of configuring things. It was interesting to read the other day that Christian seems to have the same impression of the complexity of SCR. I remember when I first tried I thought it looked pretty cool but started running into problems.
So what you’re comparing here isn’t really apples with apples. A long way back Camel provided a bunch of Spring XML sugar to make configuring Camel simpler. This was obviously a good thing because setting up Camel was (and is) hard. To this day people still use the Spring syntax for building their Camel routes. OSGi blueprint was effectively a move by Spring to standardise the Spring DM container, and so unsurprisingly blueprint looks a lot like Spring. Some people did the work to port the Camel Spring configuration to OSGi blueprint, and that’s why Camel is easy to use in blueprint.
If someone actually spent some time putting together a nice integration with SCR then I’m sure that using SCR would be at least as easy as blueprint. The problem here is that relatively few SCR developers/users use Camel, and the ones that do are just told to “use blueprint”.
That DS is in its second generation and only now getting around to transactions is telling. Either it has reached its natural boundaries and is now over-reaching or wasn’t full thought out.
DS is actually working on its fifth release, and transactions are nowhere to be seen. You may be referring to the Transaction Control specification, which is separate from DS. They can be used together very effectively, but you could equally use Transaction Control with blueprint.
DS is actually one of the “good citizens” of the DI world in that it deliberately does less in order to do it well. There’s no dependency proxying, no aspects, just the code that you wrote injected with some other code that someone wrote.
To me it's a component and service bootstrapping mechanism which represents a small portion of the world I work in - transforms, routing, EIPs, etc. I've no reason to embrace it or deny it unless it either makes my job much easier or I can't live without it. So far adding Camel SCR and DS into the middleware just results in one more thing I have to deal with.
This is a perfectly acceptable viewpoint. If the fundamental limitations of the blueprint model aren’t a problem for you then switching right now is almost certainly unnecessary.
I think Blueprint works well these days and has come a long way in the past 3 years. The Aries team is to be commended for some great work.
Aries Blueprint has had a lot of extensions and improvements over the last three years. Sadly the same cannot be said for the specifications or other implementations. Aries Blueprint is very much the last implementation standing, and there has been no effort to standardise the new features (or even to try fixing the problems with the original standard). The set of RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance is very telling.
As far as Aries blueprint is concerned, the main reason that it is still alive seems to be the fact that it was included in Karaf, and that Karaf provides Camel integration alongside it. Even Karaf itself is starting to move to use DS internally, offering blueprint as something for applications to use.
I’ve been surprised by the near religious zeal of some of the DS advocates.
Most OSGi developers I know (myself included) who really start to use DS consider it to be roughly equivalent to magic. The fact that the model can be as simple as it is and yet still flexible, correct and safe is both surprising and pleasing. Moving back to “not DS” is usually pretty painful and reminds people why they love DS so much.
I'll be interested in seeing the DS semantics and proxies for CDI. Heh. Proxies are another technology that I don't care about one way or the other as long as things work well and don't require a lot of configuration. So it’s great if we can get rid of proxies but not so great if I now have to trade that off for configuration of start up order on services to make sure everything is running before Camel routes come up.
Actually, this is one of the places where DS really shines. If you write a DS component properly (i.e. without trying to dig out of the DS lifecycle) then startup ordering ceases to be an issue.
Again, someone with a little time and expertise would probably find that Camel + DS can be a really effective solution. The problem is finding the person who has the time, expertise and inclination…
Tim Ward
Apache Aries PMC Member,
OSGi IoT Expert Group Chair,
Author Enterprise OSGi in Action
timothyjward@apache.org<ma...@apache.org>
On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gn...@apache.org>> wrote:
I can happily review a patch if you're fancy writing one...
And I disagree with the 'blueprint is dead and nobody cares about it anymore'. What's dead is the blueprint osgi specification for blueprint, not the Aries Blueprint project. I've recently added a bunch of important features related to spring in blueprint.
DS also has some drawbacks as it's not extensible at all : this is leading the OSGi Alliance to write a new spec for transaction support !!!
I think the CDI+DS extension I've been working on those past weeks could bring the best of both world : strong DS semantics for the OSGi bits, but extensibility and support for proxies provided by CDI ;-)
2016-07-12 17:24 GMT+02:00 Brad Johnson <br...@mediadriver.com>>:
David,
I'm all for multilocation support in blueprint. Can't wait for it. But it sounds like your saying blueprint is dead and nobody cares about it anymore so it doesn't seem likely to happen anytime soon. It certainly wouldn't be relevant to Fuse which uses R4 in any case.
On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <br...@mediadriver.com>> wrote:
The features file can have statements like this:
<configfile finalname="/etc/com.foo.cfg" override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
<configfile finalname="/etc/com.bar.cfg" override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
....etc....
That's off the top of my head so take it with a grain of salt for syntax.
When you run the features install it will overwrite the files in the etc directory with the ones in the maven bundle which have now been updated. So instead of modifying configuration files in the etc directory you modifying them in your Maven configuration project and recompile the bundle and then pull it from the repo
in order to update the values.
But you can still modify them in the etc if you wanted. You just have to make sure you have the cm properties set to reload.
<cm:property-placeholder persistent-id="com.foo" update-strategy="reload">
On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <pa...@faw.jku.at>> wrote:
Brad, if I understand your approach too that would lead to not being able to dynamically change common properties in a single config place during runtime, as the fill made by maven would be only done once at build time right? But at runtime I would need to that as David mention, still n times right?
as a use case for instance, with blueprint:cm update-strategy configured as 'reload' in combination with felix-fileinstall as directory watcher, bundles are reloaded automatically so that when I modify at anytime during runtime a property e.g with just a text editor the bundle is initiated again with the new property values which is a quite nice feature
best
Pablo
On 12/07/2016 12:31 AM, David Jencks wrote:
I’d like to make sure I understand what you are doing here…. IIUC during the build of your project you are generating multiple configuration files with the same or similar content, and each of these is loaded into a configuration which is bound to a particular bundle location? So, at build time you can change all the duplicate properties at once but if you need to change them later you have to alter n (== number of duplicate configs) independently? Whereas if you had multi-location support (and possibly multi-pid support such as DS provides) you could share a single Configuration and change the property while the framework was running in one place?
thanks
david jencks
On Jul 11, 2016, at 1:42 PM, Brad Johnson <br...@mediadriver.com>> wrote:
Pablo,
One possible solution to this problem that I'm currently looking at is using a configuration bundle along with my features bundle. In the configuration bundle I have all the cfg files and use properties placeholders ${value} to set the value for key/value.
In the POM I load properties files using the Maven properties plugin and that lets me set a global set of properties values that can be used in filling in the cfg values. So if a port or URI is shared across a large number of them that automatically gets filled in. The features file can then specify the cfg files to install and what name to install them with.
This gets rid of a lot of tedium and by using profiles I should be able to switch dev, test and production, and have the properties automatically set correctly.
I'd like to modify this a bit so that dev, test and product cfg files are all created simultaneously and simply installed in different directories inside the configuration bundle. Then by using different features installs I can easily switch between the different configurations without having to tediously edit each configuration file.
Brad
On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com>> wrote:
Does Camel/Fuse even support DS? I haven't found any documentation saying otherwise. I've only found camel-scr which uses Felix-specific annotations and not DS.
On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com>> wrote:
David,
That is some pretty extreme and wild speculation alright. How does one use blueprint to not use OSGi appropriately? In the 5 years I've been consulting with Fuse/Karaf/OSGi and going to various clients not one of them used or uses DS. Not one. They all use bundles, services, and Camel with blueprint. The last time I worked with DS I didn't find it provided any serious advantage and added another layer that I'd have to teach my clients. Not that I wouldn't consider it or use it if I found a real advantage but I haven't.
Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi 4.x land much less 5 or 6.
So for Camel are you using the Java DSL?
Brad
On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <da...@yahoo.com>> wrote:
I don’t think karaf is at osgi R4.2 any more, I suggest you look at the osgi R5 or R6 config admin spec for “multi location”.
You guys might be using blueprint every day, but there is no OSGI spec work to keep it up to date or even specify obviously necessary features such as config admin integration. If blueprint is so great why aren’t the proponents keeping the spec related to current OSGI? This is a part of my, admittedly extreme, theory that use of blueprint is related to not wanting to make the app actually use osgi appropriately.
And, the project I work on every day uses DS exclusively and still finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
david jencks
On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com>> wrote:
It is in here; https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
A bundle is in aries bound to the pid. So it is actually working as expected, bit of
a hassle since spring-dm allowed it.
And yes selling DS into “regular" organizations is about as easy as selling snow in Alaska.
/je
On Jul 7, 2016, at 12:00 PM, Brad Johnson <br...@mediadriver.com>> wrote:
David,
You live in a very different world than I do. In all the consulting I do with Fuse/karaf blueprint is used almost exclusively. I understand DS and its uses but also its limits and overhead. It's like telling me one should only use Camel Java DSL. That may be one's perspective but that isn't everyone's.
Brad
On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <da...@yahoo.com>> wrote:
IMNSHO blueprint is only really plausible if you have a large amount of Spring based code and you need to convert it to be sort of osgi-compatible really quickly without understanding osgi or the code. Otherwise taking the time to understand DS and use it is much more satisfactory. DS provides this configuration override ability with support for multiple pids, although only one of the pids can turn out to be a factory configuration. There’s no obvious way of correlating factory configurations, so this restriction makes some sense.
I don’t think there really are any blueprint folks. The cm stuff, while obviously required to make the spec remotely plausible, hasn’t made it into the spec in the many many years it’s been sitting around.
david jencks
On Jul 7, 2016, at 10:41 AM, Brad Johnson <br...@mediadriver.com>> wrote:
If I were to sit down with the blueprint folks today to create a wish list one thing I'd like to see is for an ability to have a configuration hierarchy specified with parent/child relationships much like one has in Maven. Have a base configuration file and be able to have another cfg file specify that one as its parent. Override properties or add them to the child. When the configuration admin fires up it would read up the chain and construct the properties.
On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <br...@mediadriver.com>> wrote:
Ray,
If I understand your question right the answer is the Aries extension is referencing configuration. In karaf/fuse for example the following:
<cm:property-placeholder persistent-id="com.my.foo" update-strategy="reload">
will load properties from etc/com.my.foo.cfg
Installing that file is done either manually or by use of a features file.
Whenever I've attempted to use the PID in more than one bundle it has failed and I don't think it is permitted. That's a problem I think and something that should be fixed through some other configuration management mechanism. Making microservices that might share common properties, for example, becomes problematic in that regard and I've resorted to using my own OSGi services to overcome that problem.
Brad
On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <ra...@liferay.com>> wrote:
Ok, so after a brief review the cm schema is an Aries extension and it doesn't appear to support the location binding.
However, it's unclear to me whether this extension is creating the configuration or merely referencing one from outside.
Any Aries gurus can answer that?
- Ray
On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <da...@yahoo.com>> wrote:
I’m not really familiar with blueprint cm but I’d expect that to indicate which pid to use to fetch the config from config admin and in the ... how to map configuration propertiething blueprint substitution knows about. Is that really instructions to create a new configuration and populate it with data (what a management agent does)?
david jencks
On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com>> wrote:
David, I agree with everything you've said, however this looks like blueprint being the agent here:
<cm:property-placeholder persistent-id="my.id<http://my.id/>" update-strategy="reload">
...
</cm:property-placeholder>
- Ray
On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <da...@yahoo.com>> wrote:
No, blueprint cm shouldn’t really know about the multi-location. The management agent that is creating the configuration should be setting the bundle location to the multi-location ”?”.
david jencks
On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at>> wrote:
I see and would it possible to configure which method is invoked from Blueprint?
This is how I do it:
<cm:property-placeholder persistent-id="my.id<http://my.id/>" update-strategy="reload">
...
</cm:property-placeholder>
is there perhaps some blueprint property where I can tune the second argument in the createFactoryConfiguration?
Because it looks like the fact of using config admin through blueprint binds the PID to the first bundle using it
best
Pablo
On 07/07/2016 4:41 PM, Raymond Auge wrote:
As long as configurations are not bound to a bundle they can be used by any bundle.
The exception clearly shows that the configuration is bound to a bundle.
Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
HTH,
- Ray
On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <br...@mediadriver.com>> wrote:
I don't think that's possible.
On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pa...@faw.jku.at>> wrote:
Hello All,
Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm<http://org.osgi.service.cm/>.ManagedService, id=214, bundle=86/initial@reference:file:../plugin-1/<mailto:bundle=86/initial@reference:file:../plugin-1/>]: No visibility to configuration bound to initial@reference:file:../plugin-2/<mailto:initial@reference:file:../plugin-2/>
I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959
However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
As a workaround I can make a config file per bundle that needs it....
As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
ID|State |Level|Name
5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
--
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
--
Raymond Augé<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect Liferay, Inc.<http://www.liferay.com/> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance<http://osgi.org/> (@OSGiAlliance)
--
Raymond Augé<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect Liferay, Inc.<http://www.liferay.com/> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance<http://osgi.org/> (@OSGiAlliance)
--
Raymond Augé<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect Liferay, Inc.<http://www.liferay.com/> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance<http://osgi.org/> (@OSGiAlliance)
--
Matt Sicker <bo...@gmail.com>>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
--
Matt Sicker <bo...@gmail.com>>
--
Matt Sicker <bo...@gmail.com>>
Re: blueprint:cm multiple bundle but same config file
Posted by Matt Sicker <bo...@gmail.com>.
Can you include scanning services or certain types of annotated services to
inject camel things into? That way you can use DS components more easily.
On 1 August 2016 at 20:03, Brad Johnson <br...@mediadriver.com>
wrote:
> The CamelContext disambiguation obviously is a next step...
>
> On Mon, Aug 1, 2016 at 8:01 PM, Brad Johnson <brad.johnson@mediadriver.com
> > wrote:
>
>> I'd thought that it was possible since the examples have a SimpleRegistry
>> and mention using it to register beans. But when I looked at the
>> AbstractCamelRunner it became obvious that that would not work.
>>
>> I'm trying something by creating a new SCRRegistry type just for the
>> sake of experimentation. Internally it has a CompositeRegistry and the
>> AbstractCamelRunner which I'm modifying uses the new SCRRegistry which has
>> a setter or on it for both a SimpleRegistry and an OsgiRegistry. If it
>> finds the bundle context it creates the OSGi service registry and adds it
>> and in either case adds a SimpleRegistry after it.
>>
>>
>> protected void createCamelContext(final BundleContext bundleContext,
>> final Map<String, String> props) {
>> if (bundleContext != null) {
>> OsgiServiceRegistry osgiRegistry = new
>> OsgiServiceRegistry(bundleContext);
>> context = new OsgiDefaultCamelContext(bundleContext,
>> osgiRegistry);
>> // Setup the application context classloader with the bundle
>> classloader
>> context.setApplicationContextClassLoader(new
>> BundleDelegatingClassLoader(bundleContext.getBundle()));
>> // and make sure the TCCL is our classloader
>>
>> Thread.currentThread().setContextClassLoader(context.getApplicationContextClassLoader());
>> this.registry.setOsgiRegistry(osgiRegistry);
>> }
>> registry.setSimpleRegistry(new SimpleRegistry());
>> context = new DefaultCamelContext(registry);
>>
>>
>>
>> Inside the SCRRegistry it delegates all its Registry interface calls to
>> the CompositeRegistry but it keeps a handle on the SimpleRegistry. So to
>> register a class one can do the following:
>>
>> registry.register(POValidator.class);
>>
>> In this case it's very simple instantiation of the no-arg constructor and
>> then looking for EndpointInject annotations and setting it to the
>> ProducerTemplate and the URI it finds. This is such a quick and naive cut
>> that I'm not even checking to see if there's an endpoint by that name in
>> the registry already which I could just use instead. Obviously if I do
>> anything more with this I'll look at reusing the existing libraries for
>> annotation processing instead of writing this stuff by hand. I still
>> haven't tested this by throwing it in karaf with Felix or any other OSGi
>> implementation.
>>
>> public void register(Class clazz){
>> try {
>> Object o=clazz.newInstance();
>> for(Field declaredField:clazz.getDeclaredFields())
>> {
>> for(EndpointInject endpoint:
>> declaredField.getAnnotationsByType(EndpointInject.class))
>> {
>> declaredField.setAccessible(true);
>> ProducerTemplate template = camelContext.createProducerTemplate();
>> template.setDefaultEndpointUri(endpoint.uri());
>> declaredField.set(o,template);
>> }
>> }
>> this.simpleRegistry.put(clazz.getSimpleName(), o);
>> } catch (InstantiationException | IllegalAccessException e) {
>> //TODO log..
>> }
>> }
>>
>> On Mon, Aug 1, 2016 at 6:33 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> Can you even make a semi-private service in DS/SCR? What could the
>>> equivalent be to a blueprint bean that isn't exported as a service? Or is
>>> the philosophy to make all services public in DS?
>>>
>>> On 1 August 2016 at 18:12, Brad Johnson <br...@mediadriver.com>
>>> wrote:
>>>
>>>> Tim,
>>>>
>>>> After working with DS and SCR a little I can understand its benefits.
>>>> One obvious advantage was being able to write basic JUnit tests to test my
>>>> routes without having to fire up CBTS. I've always disliked working in XML
>>>> so it is odd being in the position like I sound like I'm the one
>>>> championing it.
>>>>
>>>> The main problem right now with Camel is that while SCR handles all the
>>>> external items there isn't a way to do any injection of "local"
>>>> dependencies. By that I mean within my own bundle I might have validators,
>>>> handlers, local data models, etc. that I want to stand up and run in my
>>>> Camel routes. Camel SCR doesn't have a mechanism for doing that.
>>>>
>>>> When one runs it locally in the IDE it fires up a SimpleRegistry and
>>>> uses that to register everything and in that case you can manually add your
>>>> own beans before setting up route definitions. If the bundle is running
>>>> where it has a bundle context it instead fires up an
>>>> OsgiServiceRegistry(don't recall the full name.) In that case you can't add
>>>> your local beans.
>>>>
>>>> I noted that there is a CompositeRegistry in the AbstractCamelRunner
>>>> and perhaps that should always be the one used. If one boots up and an
>>>> OSGi service registry is created both it and the SimpleRegistry are added
>>>> to the CompositeRegistry but one can access the SimpleRegistry in order to
>>>> add one's local dependencies for Camel routes.
>>>>
>>>> On Wed, Jul 13, 2016 at 3:34 AM, Timothy Ward <ti...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi Brad,
>>>>>
>>>>> I’ve been watching this thread for a while, and you’ve finally managed
>>>>> to draw me in :)
>>>>>
>>>>>
>>>>> On 12 Jul 2016, at 17:42, Brad Johnson <br...@mediadriver.com>
>>>>> wrote:
>>>>>
>>>>> Guillaume,
>>>>>
>>>>> I'm still using Blueprint and have found Camel/SCR to be a pain to
>>>>> work with. It provides no tangible benefit if one is using Blueprint for
>>>>> routes and dependency injection anyway as it simply introduces one more way
>>>>> of configuring things. It was interesting to read the other day that
>>>>> Christian seems to have the same impression of the complexity of SCR. I
>>>>> remember when I first tried I thought it looked pretty cool but started
>>>>> running into problems.
>>>>>
>>>>>
>>>>> So what you’re comparing here isn’t really apples with apples. A long
>>>>> way back Camel provided a bunch of Spring XML sugar to make configuring
>>>>> Camel simpler. This was obviously a good thing because setting up Camel was
>>>>> (and is) hard. To this day people still use the Spring syntax for building
>>>>> their Camel routes. OSGi blueprint was effectively a move by Spring to
>>>>> standardise the Spring DM container, and so unsurprisingly blueprint looks
>>>>> a lot like Spring. Some people did the work to port the Camel Spring
>>>>> configuration to OSGi blueprint, and that’s why Camel is easy to use in
>>>>> blueprint.
>>>>>
>>>>> If someone actually spent some time putting together a nice
>>>>> integration with SCR then I’m sure that using SCR would be at least as easy
>>>>> as blueprint. The problem here is that relatively few SCR developers/users
>>>>> use Camel, and the ones that do are just told to “use blueprint”.
>>>>>
>>>>> That DS is in its second generation and only now getting around to
>>>>> transactions is telling. Either it has reached its natural boundaries and
>>>>> is now over-reaching or wasn’t full thought out.
>>>>>
>>>>>
>>>>> DS is actually working on its fifth release, and transactions are
>>>>> nowhere to be seen. You may be referring to the Transaction Control
>>>>> specification, which is separate from DS. They can be used together very
>>>>> effectively, but you could equally use Transaction Control with blueprint.
>>>>>
>>>>> DS is actually one of the “good citizens” of the DI world in that it
>>>>> deliberately does less in order to do it well. There’s no dependency
>>>>> proxying, no aspects, just the code that you wrote injected with some other
>>>>> code that someone wrote.
>>>>>
>>>>> To me it's a component and service bootstrapping mechanism which
>>>>> represents a small portion of the world I work in - transforms, routing,
>>>>> EIPs, etc. I've no reason to embrace it or deny it unless it either makes
>>>>> my job much easier or I can't live without it. So far adding Camel SCR and
>>>>> DS into the middleware just results in one more thing I have to deal with.
>>>>>
>>>>>
>>>>> This is a perfectly acceptable viewpoint. If the fundamental
>>>>> limitations of the blueprint model aren’t a problem for you then switching
>>>>> right now is almost certainly unnecessary.
>>>>>
>>>>>
>>>>> I think Blueprint works well these days and has come a long way in the
>>>>> past 3 years. The Aries team is to be commended for some great work.
>>>>>
>>>>>
>>>>> Aries Blueprint has had a lot of extensions and improvements over the
>>>>> last three years. Sadly the same cannot be said for the specifications or
>>>>> other implementations. Aries Blueprint is very much the last implementation
>>>>> standing, and there has been no effort to standardise the new features (or
>>>>> even to try fixing the problems with the original standard). The set of
>>>>> RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance is
>>>>> very telling.
>>>>>
>>>>> As far as Aries blueprint is concerned, the main reason that it is
>>>>> still alive seems to be the fact that it was included in Karaf, and that
>>>>> Karaf provides Camel integration alongside it. Even Karaf itself is
>>>>> starting to move to use DS internally, offering blueprint as something for
>>>>> applications to use.
>>>>>
>>>>>
>>>>> I’ve been surprised by the near religious zeal of some of the DS
>>>>> advocates.
>>>>>
>>>>>
>>>>> Most OSGi developers I know (myself included) who really start to use
>>>>> DS consider it to be roughly equivalent to magic. The fact that the model
>>>>> can be as simple as it is and yet still flexible, correct and safe is both
>>>>> surprising and pleasing. Moving back to “not DS” is usually pretty painful
>>>>> and reminds people why they love DS so much.
>>>>>
>>>>> I'll be interested in seeing the DS semantics and proxies for CDI.
>>>>> Heh. Proxies are another technology that I don't care about one way or the
>>>>> other as long as things work well and don't require a lot of
>>>>> configuration. So it’s great if we can get rid of proxies but not so great
>>>>> if I now have to trade that off for configuration of start up order on
>>>>> services to make sure everything is running before Camel routes come up.
>>>>>
>>>>>
>>>>> Actually, this is one of the places where DS really shines. If you
>>>>> write a DS component properly (i.e. without trying to dig out of the DS
>>>>> lifecycle) then startup ordering ceases to be an issue.
>>>>>
>>>>> Again, someone with a little time and expertise would probably find
>>>>> that Camel + DS can be a really effective solution. The problem is finding
>>>>> the person who has the time, expertise and inclination…
>>>>>
>>>>> Tim Ward
>>>>>
>>>>> Apache Aries PMC Member,
>>>>> OSGi IoT Expert Group Chair,
>>>>> Author Enterprise OSGi in Action
>>>>> timothyjward@apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gn...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> I can happily review a patch if you're fancy writing one...
>>>>>>
>>>>>> And I disagree with the 'blueprint is dead and nobody cares about it
>>>>>> anymore'. What's dead is the blueprint osgi specification for blueprint,
>>>>>> not the Aries Blueprint project. I've recently added a bunch of important
>>>>>> features related to spring in blueprint.
>>>>>>
>>>>>> DS also has some drawbacks as it's not extensible at all : this is
>>>>>> leading the OSGi Alliance to write a new spec for transaction support !!!
>>>>>>
>>>>>> I think the CDI+DS extension I've been working on those past weeks
>>>>>> could bring the best of both world : strong DS semantics for the OSGi bits,
>>>>>> but extensibility and support for proxies provided by CDI ;-)
>>>>>>
>>>>>>
>>>>>> 2016-07-12 17:24 GMT+02:00 Brad Johnson <brad.johnson@mediadriver.com
>>>>>> >:
>>>>>>
>>>>>>> David,
>>>>>>>
>>>>>>> I'm all for multilocation support in blueprint. Can't wait for it.
>>>>>>> But it sounds like your saying blueprint is dead and nobody cares about
>>>>>>> it anymore so it doesn't seem likely to happen anytime soon. It certainly
>>>>>>> wouldn't be relevant to Fuse which uses R4 in any case.
>>>>>>>
>>>>>>> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <
>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>
>>>>>>>> The features file can have statements like this:
>>>>>>>>
>>>>>>>>
>>>>>>>> <configfile finalname="/etc/com.foo.cfg"
>>>>>>>> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
>>>>>>>> <configfile finalname="/etc/com.bar.cfg"
>>>>>>>> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
>>>>>>>> ....etc....
>>>>>>>> That's off the top of my head so take it with a grain of salt for
>>>>>>>> syntax.
>>>>>>>>
>>>>>>>> When you run the features install it will overwrite the files in
>>>>>>>> the etc directory with the ones in the maven bundle which have now been
>>>>>>>> updated. So instead of modifying configuration files in the etc directory
>>>>>>>> you modifying them in your Maven configuration project and recompile the
>>>>>>>> bundle and then pull it from the repo
>>>>>>>> in order to update the values.
>>>>>>>>
>>>>>>>> But you can still modify them in the etc if you wanted. You just
>>>>>>>> have to make sure you have the cm properties set to reload.
>>>>>>>>
>>>>>>>> <cm:property-placeholder persistent-id="com.foo"
>>>>>>>> update-strategy="reload">
>>>>>>>>
>>>>>>>> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <
>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>
>>>>>>>>> Brad, if I understand your approach too that would lead to not
>>>>>>>>> being able to dynamically change common properties in a single config place
>>>>>>>>> during runtime, as the fill made by maven would be only done once at build
>>>>>>>>> time right? But at runtime I would need to that as David mention, still n
>>>>>>>>> times right?
>>>>>>>>>
>>>>>>>>> as a use case for instance, with blueprint:cm update-strategy
>>>>>>>>> configured as 'reload' in combination with felix-fileinstall as directory
>>>>>>>>> watcher, bundles are reloaded automatically so that when I modify at
>>>>>>>>> anytime during runtime a property e.g with just a text editor the bundle is
>>>>>>>>> initiated again with the new property values which is a quite nice feature
>>>>>>>>>
>>>>>>>>> best
>>>>>>>>>
>>>>>>>>> Pablo
>>>>>>>>>
>>>>>>>>> On 12/07/2016 12:31 AM, David Jencks wrote:
>>>>>>>>>
>>>>>>>>> I’d like to make sure I understand what you are doing here…. IIUC
>>>>>>>>> during the build of your project you are generating multiple configuration
>>>>>>>>> files with the same or similar content, and each of these is loaded into a
>>>>>>>>> configuration which is bound to a particular bundle location? So, at build
>>>>>>>>> time you can change all the duplicate properties at once but if you need to
>>>>>>>>> change them later you have to alter n (== number of duplicate configs)
>>>>>>>>> independently? Whereas if you had multi-location support (and possibly
>>>>>>>>> multi-pid support such as DS provides) you could share a single
>>>>>>>>> Configuration and change the property while the framework was running in
>>>>>>>>> one place?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <
>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>
>>>>>>>>> Pablo,
>>>>>>>>>
>>>>>>>>> One possible solution to this problem that I'm currently looking
>>>>>>>>> at is using a configuration bundle along with my features bundle. In the
>>>>>>>>> configuration bundle I have all the cfg files and use properties
>>>>>>>>> placeholders ${value} to set the value for key/value.
>>>>>>>>>
>>>>>>>>> In the POM I load properties files using the Maven properties
>>>>>>>>> plugin and that lets me set a global set of properties values that can be
>>>>>>>>> used in filling in the cfg values. So if a port or URI is shared across a
>>>>>>>>> large number of them that automatically gets filled in. The features file
>>>>>>>>> can then specify the cfg files to install and what name to install them
>>>>>>>>> with.
>>>>>>>>>
>>>>>>>>> This gets rid of a lot of tedium and by using profiles I should be
>>>>>>>>> able to switch dev, test and production, and have the properties
>>>>>>>>> automatically set correctly.
>>>>>>>>>
>>>>>>>>> I'd like to modify this a bit so that dev, test and product cfg
>>>>>>>>> files are all created simultaneously and simply installed in different
>>>>>>>>> directories inside the configuration bundle. Then by using different
>>>>>>>>> features installs I can easily switch between the different configurations
>>>>>>>>> without having to tediously edit each configuration file.
>>>>>>>>>
>>>>>>>>> Brad
>>>>>>>>>
>>>>>>>>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Does Camel/Fuse even support DS? I haven't found any
>>>>>>>>>> documentation saying otherwise. I've only found camel-scr which uses
>>>>>>>>>> Felix-specific annotations and not DS.
>>>>>>>>>>
>>>>>>>>>> On 7 July 2016 at 14:32, Brad Johnson <
>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> David,
>>>>>>>>>>>
>>>>>>>>>>> That is some pretty extreme and wild speculation alright. How
>>>>>>>>>>> does one use blueprint to not use OSGi appropriately? In the 5 years I've
>>>>>>>>>>> been consulting with Fuse/Karaf/OSGi and going to various clients not one
>>>>>>>>>>> of them used or uses DS. Not one. They all use bundles, services, and
>>>>>>>>>>> Camel with blueprint. The last time I worked with DS I didn't find it
>>>>>>>>>>> provided any serious advantage and added another layer that I'd have to
>>>>>>>>>>> teach my clients. Not that I wouldn't consider it or use it if I found a
>>>>>>>>>>> real advantage but I haven't.
>>>>>>>>>>>
>>>>>>>>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in
>>>>>>>>>>> OSGi 4.x land much less 5 or 6.
>>>>>>>>>>>
>>>>>>>>>>> So for Camel are you using the Java DSL?
>>>>>>>>>>>
>>>>>>>>>>> Brad
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <
>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you
>>>>>>>>>>>> look at the osgi R5 or R6 config admin spec for “multi location”.
>>>>>>>>>>>>
>>>>>>>>>>>> You guys might be using blueprint every day, but there is no
>>>>>>>>>>>> OSGI spec work to keep it up to date or even specify obviously necessary
>>>>>>>>>>>> features such as config admin integration. If blueprint is so great why
>>>>>>>>>>>> aren’t the proponents keeping the spec related to current OSGI? This is a
>>>>>>>>>>>> part of my, admittedly extreme, theory that use of blueprint is related to
>>>>>>>>>>>> not wanting to make the app actually use osgi appropriately.
>>>>>>>>>>>>
>>>>>>>>>>>> And, the project I work on every day uses DS exclusively and
>>>>>>>>>>>> still finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>>>>>>>>>>
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> It is in here;
>>>>>>>>>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>>>>>>>>>>
>>>>>>>>>>>> A bundle is in aries bound to the pid. So it is actually
>>>>>>>>>>>> working as expected, bit of
>>>>>>>>>>>> a hassle since spring-dm allowed it.
>>>>>>>>>>>>
>>>>>>>>>>>> And yes selling DS into “regular" organizations is about as
>>>>>>>>>>>> easy as selling snow in Alaska.
>>>>>>>>>>>>
>>>>>>>>>>>> /je
>>>>>>>>>>>>
>>>>>>>>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <
>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> David,
>>>>>>>>>>>>
>>>>>>>>>>>> You live in a very different world than I do. In all the
>>>>>>>>>>>> consulting I do with Fuse/karaf blueprint is used almost exclusively. I
>>>>>>>>>>>> understand DS and its uses but also its limits and overhead. It's like
>>>>>>>>>>>> telling me one should only use Camel Java DSL. That may be one's
>>>>>>>>>>>> perspective but that isn't everyone's.
>>>>>>>>>>>>
>>>>>>>>>>>> Brad
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <
>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> IMNSHO blueprint is only really plausible if you have a large
>>>>>>>>>>>>> amount of Spring based code and you need to convert it to be sort of
>>>>>>>>>>>>> osgi-compatible really quickly without understanding osgi or the code.
>>>>>>>>>>>>> Otherwise taking the time to understand DS and use it is much more
>>>>>>>>>>>>> satisfactory. DS provides this configuration override ability with support
>>>>>>>>>>>>> for multiple pids, although only one of the pids can turn out to be a
>>>>>>>>>>>>> factory configuration. There’s no obvious way of correlating factory
>>>>>>>>>>>>> configurations, so this restriction makes some sense.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don’t think there really are any blueprint folks. The cm
>>>>>>>>>>>>> stuff, while obviously required to make the spec remotely plausible, hasn’t
>>>>>>>>>>>>> made it into the spec in the many many years it’s been sitting around.
>>>>>>>>>>>>>
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <
>>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> If I were to sit down with the blueprint folks today to create
>>>>>>>>>>>>> a wish list one thing I'd like to see is for an ability to have a
>>>>>>>>>>>>> configuration hierarchy specified with parent/child relationships much like
>>>>>>>>>>>>> one has in Maven. Have a base configuration file and be able to have
>>>>>>>>>>>>> another cfg file specify that one as its parent. Override properties or add
>>>>>>>>>>>>> them to the child. When the configuration admin fires up it would read up
>>>>>>>>>>>>> the chain and construct the properties.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ray,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If I understand your question right the answer is the Aries
>>>>>>>>>>>>>> extension is referencing configuration. In karaf/fuse for example the
>>>>>>>>>>>>>> following:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Installing that file is done either manually or by use of a
>>>>>>>>>>>>>> features file.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Whenever I've attempted to use the PID in more than one
>>>>>>>>>>>>>> bundle it has failed and I don't think it is permitted. That's a problem I
>>>>>>>>>>>>>> think and something that should be fixed through some other configuration
>>>>>>>>>>>>>> management mechanism. Making microservices that might share common
>>>>>>>>>>>>>> properties, for example, becomes problematic in that regard and I've
>>>>>>>>>>>>>> resorted to using my own OSGi services to overcome that problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Brad
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ok, so after a brief review the cm schema is an Aries
>>>>>>>>>>>>>>> extension and it doesn't appear to support the location binding.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, it's unclear to me whether this extension is
>>>>>>>>>>>>>>> creating the configuration or merely referencing one from outside.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any Aries gurus can answer that?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <
>>>>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I’m not really familiar with blueprint cm but I’d expect
>>>>>>>>>>>>>>>> that to indicate which pid to use to fetch the config from config admin and
>>>>>>>>>>>>>>>> in the ... how to map configuration propertiething blueprint substitution
>>>>>>>>>>>>>>>> knows about. Is that really instructions to create a new configuration and
>>>>>>>>>>>>>>>> populate it with data (what a management agent does)?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <
>>>>>>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David, I agree with everything you've said, however this
>>>>>>>>>>>>>>>> looks like blueprint being the agent here:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, blueprint cm shouldn’t really know about the
>>>>>>>>>>>>>>>>> multi-location. The management agent that is creating the configuration
>>>>>>>>>>>>>>>>> should be setting the bundle location to the multi-location ”?”.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I see and would it possible to configure which method is
>>>>>>>>>>>>>>>>> invoked from Blueprint?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is how I do it:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> is there perhaps some blueprint property where I can tune
>>>>>>>>>>>>>>>>> the second argument in the createFactoryConfiguration?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because it looks like the fact of using config admin
>>>>>>>>>>>>>>>>> through blueprint binds the PID to the first bundle using it
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>>>> Pablo
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As long as configurations are not bound to a bundle they
>>>>>>>>>>>>>>>>> can be used by any bundle.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The exception clearly shows that the configuration is
>>>>>>>>>>>>>>>>> bound to a bundle.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Creating an unbound configuration requires passing a "?"
>>>>>>>>>>>>>>>>> as the second arguments to getConfiguration/createFactoryConfiguration
>>>>>>>>>>>>>>>>> methods of CM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> HTH,
>>>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Is it possible to use same config file from
>>>>>>>>>>>>>>>>>>> multiple bundles while using Config Admin with blueprint Blueprint?
>>>>>>>>>>>>>>>>>>> Because, I can't manage to do that, I get the following error:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No
>>>>>>>>>>>>>>>>>>> visibility to configuration bound to
>>>>>>>>>>>>>>>>>>> initial@reference:file:../plugin-2/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> However, I fear that this is a problem in the aries
>>>>>>>>>>>>>>>>>>> blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>>>>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>>>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As a workaround I can make a config file per bundle that
>>>>>>>>>>>>>>>>>>> needs it....
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As follows the versions and bundles that I'm using
>>>>>>>>>>>>>>>>>>> related to the container (Running on top of Equinox 3.11):
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support
>>>>>>>>>>>>>>>>>>> for JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core
>>>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API
>>>>>>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM
>>>>>>>>>>>>>>>>>>> (1.0.7)|1.0.7
>>>>>>>>>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core
>>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>>>>> (1.5.0)|1.5.0
>>>>>>>>>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>>>>> Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed
>>>>>>>>>>>>>>>>>>> Contexts (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API
>>>>>>>>>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction
>>>>>>>>>>>>>>>>>>> Blueprint (1.1.1)|1.1.1
>>>>>>>>>>>>>>>>>>> 73|Active | 2|Aries JPA Container API
>>>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for
>>>>>>>>>>>>>>>>>>> Legacy Runtimes (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>>>>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint
>>>>>>>>>>>>>>>>>>> Annotation API (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction
>>>>>>>>>>>>>>>>>>> Blueprint (2.1.0)|2.1.0
>>>>>>>>>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API
>>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint
>>>>>>>>>>>>>>>>>>> Annotation Impl (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>>> Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service
>>>>>>>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic
>>>>>>>>>>>>>>>>>>> Weaving Bundle (1.0.8)|1.0.8
>>>>>>>>>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint
>>>>>>>>>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 11|Active | 4|Apache Felix File Install
>>>>>>>>>>>>>>>>>>> (3.5.4)|3.5.4
>>>>>>>>>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell
>>>>>>>>>>>>>>>>>>> (0.12.0)|0.12.0
>>>>>>>>>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command
>>>>>>>>>>>>>>>>>>> (0.16.0)|0.16.0
>>>>>>>>>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime
>>>>>>>>>>>>>>>>>>> (0.16.2)|0.16.2
>>>>>>>>>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management
>>>>>>>>>>>>>>>>>>> Console (1.2.8)|1.2.8
>>>>>>>>>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin
>>>>>>>>>>>>>>>>>>> Service (1.8.8)|1.8.8
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email.
>>>>>>>>>>>>>>>>>>> The recipient should check this email and any attachments for the presence
>>>>>>>>>>>>>>>>>>> of viruses. The company accepts no liability for any damage caused by any
>>>>>>>>>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>>>>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>>>>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>>>>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Warning: Although the company has taken reasonable
>>>>>>>>>>>>>>>>>>> precautions to ensure no viruses are present in this email, the company
>>>>>>>>>>>>>>>>>>> cannot accept responsibility for any loss or damage arising from the use of
>>>>>>>>>>>>>>>>>>> this email or attachments.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Red Hat, Open Source Integration
>>>>>>
>>>>>> Email: gnodet@redhat.com
>>>>>> Web: http://fusesource.com
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>
--
Matt Sicker <bo...@gmail.com>
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
The CamelContext disambiguation obviously is a next step...
On Mon, Aug 1, 2016 at 8:01 PM, Brad Johnson <br...@mediadriver.com>
wrote:
> I'd thought that it was possible since the examples have a SimpleRegistry
> and mention using it to register beans. But when I looked at the
> AbstractCamelRunner it became obvious that that would not work.
>
> I'm trying something by creating a new SCRRegistry type just for the sake
> of experimentation. Internally it has a CompositeRegistry and the
> AbstractCamelRunner which I'm modifying uses the new SCRRegistry which has
> a setter or on it for both a SimpleRegistry and an OsgiRegistry. If it
> finds the bundle context it creates the OSGi service registry and adds it
> and in either case adds a SimpleRegistry after it.
>
>
> protected void createCamelContext(final BundleContext bundleContext,
> final Map<String, String> props) {
> if (bundleContext != null) {
> OsgiServiceRegistry osgiRegistry = new
> OsgiServiceRegistry(bundleContext);
> context = new OsgiDefaultCamelContext(bundleContext,
> osgiRegistry);
> // Setup the application context classloader with the bundle
> classloader
> context.setApplicationContextClassLoader(new
> BundleDelegatingClassLoader(bundleContext.getBundle()));
> // and make sure the TCCL is our classloader
>
> Thread.currentThread().setContextClassLoader(context.getApplicationContextClassLoader());
> this.registry.setOsgiRegistry(osgiRegistry);
> }
> registry.setSimpleRegistry(new SimpleRegistry());
> context = new DefaultCamelContext(registry);
>
>
>
> Inside the SCRRegistry it delegates all its Registry interface calls to
> the CompositeRegistry but it keeps a handle on the SimpleRegistry. So to
> register a class one can do the following:
>
> registry.register(POValidator.class);
>
> In this case it's very simple instantiation of the no-arg constructor and
> then looking for EndpointInject annotations and setting it to the
> ProducerTemplate and the URI it finds. This is such a quick and naive cut
> that I'm not even checking to see if there's an endpoint by that name in
> the registry already which I could just use instead. Obviously if I do
> anything more with this I'll look at reusing the existing libraries for
> annotation processing instead of writing this stuff by hand. I still
> haven't tested this by throwing it in karaf with Felix or any other OSGi
> implementation.
>
> public void register(Class clazz){
> try {
> Object o=clazz.newInstance();
> for(Field declaredField:clazz.getDeclaredFields())
> {
> for(EndpointInject endpoint:
> declaredField.getAnnotationsByType(EndpointInject.class))
> {
> declaredField.setAccessible(true);
> ProducerTemplate template = camelContext.createProducerTemplate();
> template.setDefaultEndpointUri(endpoint.uri());
> declaredField.set(o,template);
> }
> }
> this.simpleRegistry.put(clazz.getSimpleName(), o);
> } catch (InstantiationException | IllegalAccessException e) {
> //TODO log..
> }
> }
>
> On Mon, Aug 1, 2016 at 6:33 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> Can you even make a semi-private service in DS/SCR? What could the
>> equivalent be to a blueprint bean that isn't exported as a service? Or is
>> the philosophy to make all services public in DS?
>>
>> On 1 August 2016 at 18:12, Brad Johnson <br...@mediadriver.com>
>> wrote:
>>
>>> Tim,
>>>
>>> After working with DS and SCR a little I can understand its benefits.
>>> One obvious advantage was being able to write basic JUnit tests to test my
>>> routes without having to fire up CBTS. I've always disliked working in XML
>>> so it is odd being in the position like I sound like I'm the one
>>> championing it.
>>>
>>> The main problem right now with Camel is that while SCR handles all the
>>> external items there isn't a way to do any injection of "local"
>>> dependencies. By that I mean within my own bundle I might have validators,
>>> handlers, local data models, etc. that I want to stand up and run in my
>>> Camel routes. Camel SCR doesn't have a mechanism for doing that.
>>>
>>> When one runs it locally in the IDE it fires up a SimpleRegistry and
>>> uses that to register everything and in that case you can manually add your
>>> own beans before setting up route definitions. If the bundle is running
>>> where it has a bundle context it instead fires up an
>>> OsgiServiceRegistry(don't recall the full name.) In that case you can't add
>>> your local beans.
>>>
>>> I noted that there is a CompositeRegistry in the AbstractCamelRunner and
>>> perhaps that should always be the one used. If one boots up and an OSGi
>>> service registry is created both it and the SimpleRegistry are added to the
>>> CompositeRegistry but one can access the SimpleRegistry in order to add
>>> one's local dependencies for Camel routes.
>>>
>>> On Wed, Jul 13, 2016 at 3:34 AM, Timothy Ward <ti...@apache.org>
>>> wrote:
>>>
>>>> Hi Brad,
>>>>
>>>> I’ve been watching this thread for a while, and you’ve finally managed
>>>> to draw me in :)
>>>>
>>>>
>>>> On 12 Jul 2016, at 17:42, Brad Johnson <br...@mediadriver.com>
>>>> wrote:
>>>>
>>>> Guillaume,
>>>>
>>>> I'm still using Blueprint and have found Camel/SCR to be a pain to work
>>>> with. It provides no tangible benefit if one is using Blueprint for routes
>>>> and dependency injection anyway as it simply introduces one more way of
>>>> configuring things. It was interesting to read the other day that Christian
>>>> seems to have the same impression of the complexity of SCR. I remember
>>>> when I first tried I thought it looked pretty cool but started running into
>>>> problems.
>>>>
>>>>
>>>> So what you’re comparing here isn’t really apples with apples. A long
>>>> way back Camel provided a bunch of Spring XML sugar to make configuring
>>>> Camel simpler. This was obviously a good thing because setting up Camel was
>>>> (and is) hard. To this day people still use the Spring syntax for building
>>>> their Camel routes. OSGi blueprint was effectively a move by Spring to
>>>> standardise the Spring DM container, and so unsurprisingly blueprint looks
>>>> a lot like Spring. Some people did the work to port the Camel Spring
>>>> configuration to OSGi blueprint, and that’s why Camel is easy to use in
>>>> blueprint.
>>>>
>>>> If someone actually spent some time putting together a nice integration
>>>> with SCR then I’m sure that using SCR would be at least as easy as
>>>> blueprint. The problem here is that relatively few SCR developers/users use
>>>> Camel, and the ones that do are just told to “use blueprint”.
>>>>
>>>> That DS is in its second generation and only now getting around to
>>>> transactions is telling. Either it has reached its natural boundaries and
>>>> is now over-reaching or wasn’t full thought out.
>>>>
>>>>
>>>> DS is actually working on its fifth release, and transactions are
>>>> nowhere to be seen. You may be referring to the Transaction Control
>>>> specification, which is separate from DS. They can be used together very
>>>> effectively, but you could equally use Transaction Control with blueprint.
>>>>
>>>> DS is actually one of the “good citizens” of the DI world in that it
>>>> deliberately does less in order to do it well. There’s no dependency
>>>> proxying, no aspects, just the code that you wrote injected with some other
>>>> code that someone wrote.
>>>>
>>>> To me it's a component and service bootstrapping mechanism which
>>>> represents a small portion of the world I work in - transforms, routing,
>>>> EIPs, etc. I've no reason to embrace it or deny it unless it either makes
>>>> my job much easier or I can't live without it. So far adding Camel SCR and
>>>> DS into the middleware just results in one more thing I have to deal with.
>>>>
>>>>
>>>> This is a perfectly acceptable viewpoint. If the fundamental
>>>> limitations of the blueprint model aren’t a problem for you then switching
>>>> right now is almost certainly unnecessary.
>>>>
>>>>
>>>> I think Blueprint works well these days and has come a long way in the
>>>> past 3 years. The Aries team is to be commended for some great work.
>>>>
>>>>
>>>> Aries Blueprint has had a lot of extensions and improvements over the
>>>> last three years. Sadly the same cannot be said for the specifications or
>>>> other implementations. Aries Blueprint is very much the last implementation
>>>> standing, and there has been no effort to standardise the new features (or
>>>> even to try fixing the problems with the original standard). The set of
>>>> RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance is
>>>> very telling.
>>>>
>>>> As far as Aries blueprint is concerned, the main reason that it is
>>>> still alive seems to be the fact that it was included in Karaf, and that
>>>> Karaf provides Camel integration alongside it. Even Karaf itself is
>>>> starting to move to use DS internally, offering blueprint as something for
>>>> applications to use.
>>>>
>>>>
>>>> I’ve been surprised by the near religious zeal of some of the DS
>>>> advocates.
>>>>
>>>>
>>>> Most OSGi developers I know (myself included) who really start to use
>>>> DS consider it to be roughly equivalent to magic. The fact that the model
>>>> can be as simple as it is and yet still flexible, correct and safe is both
>>>> surprising and pleasing. Moving back to “not DS” is usually pretty painful
>>>> and reminds people why they love DS so much.
>>>>
>>>> I'll be interested in seeing the DS semantics and proxies for CDI. Heh.
>>>> Proxies are another technology that I don't care about one way or the other
>>>> as long as things work well and don't require a lot of configuration. So
>>>> it’s great if we can get rid of proxies but not so great if I now have to
>>>> trade that off for configuration of start up order on services to make sure
>>>> everything is running before Camel routes come up.
>>>>
>>>>
>>>> Actually, this is one of the places where DS really shines. If you
>>>> write a DS component properly (i.e. without trying to dig out of the DS
>>>> lifecycle) then startup ordering ceases to be an issue.
>>>>
>>>> Again, someone with a little time and expertise would probably find
>>>> that Camel + DS can be a really effective solution. The problem is finding
>>>> the person who has the time, expertise and inclination…
>>>>
>>>> Tim Ward
>>>>
>>>> Apache Aries PMC Member,
>>>> OSGi IoT Expert Group Chair,
>>>> Author Enterprise OSGi in Action
>>>> timothyjward@apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gn...@apache.org>
>>>> wrote:
>>>>
>>>>> I can happily review a patch if you're fancy writing one...
>>>>>
>>>>> And I disagree with the 'blueprint is dead and nobody cares about it
>>>>> anymore'. What's dead is the blueprint osgi specification for blueprint,
>>>>> not the Aries Blueprint project. I've recently added a bunch of important
>>>>> features related to spring in blueprint.
>>>>>
>>>>> DS also has some drawbacks as it's not extensible at all : this is
>>>>> leading the OSGi Alliance to write a new spec for transaction support !!!
>>>>>
>>>>> I think the CDI+DS extension I've been working on those past weeks
>>>>> could bring the best of both world : strong DS semantics for the OSGi bits,
>>>>> but extensibility and support for proxies provided by CDI ;-)
>>>>>
>>>>>
>>>>> 2016-07-12 17:24 GMT+02:00 Brad Johnson <br...@mediadriver.com>
>>>>> :
>>>>>
>>>>>> David,
>>>>>>
>>>>>> I'm all for multilocation support in blueprint. Can't wait for it.
>>>>>> But it sounds like your saying blueprint is dead and nobody cares about it
>>>>>> anymore so it doesn't seem likely to happen anytime soon. It certainly
>>>>>> wouldn't be relevant to Fuse which uses R4 in any case.
>>>>>>
>>>>>> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <
>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>
>>>>>>> The features file can have statements like this:
>>>>>>>
>>>>>>>
>>>>>>> <configfile finalname="/etc/com.foo.cfg"
>>>>>>> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
>>>>>>> <configfile finalname="/etc/com.bar.cfg"
>>>>>>> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
>>>>>>> ....etc....
>>>>>>> That's off the top of my head so take it with a grain of salt for
>>>>>>> syntax.
>>>>>>>
>>>>>>> When you run the features install it will overwrite the files in the
>>>>>>> etc directory with the ones in the maven bundle which have now been
>>>>>>> updated. So instead of modifying configuration files in the etc directory
>>>>>>> you modifying them in your Maven configuration project and recompile the
>>>>>>> bundle and then pull it from the repo
>>>>>>> in order to update the values.
>>>>>>>
>>>>>>> But you can still modify them in the etc if you wanted. You just
>>>>>>> have to make sure you have the cm properties set to reload.
>>>>>>>
>>>>>>> <cm:property-placeholder persistent-id="com.foo"
>>>>>>> update-strategy="reload">
>>>>>>>
>>>>>>> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <
>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>
>>>>>>>> Brad, if I understand your approach too that would lead to not
>>>>>>>> being able to dynamically change common properties in a single config place
>>>>>>>> during runtime, as the fill made by maven would be only done once at build
>>>>>>>> time right? But at runtime I would need to that as David mention, still n
>>>>>>>> times right?
>>>>>>>>
>>>>>>>> as a use case for instance, with blueprint:cm update-strategy
>>>>>>>> configured as 'reload' in combination with felix-fileinstall as directory
>>>>>>>> watcher, bundles are reloaded automatically so that when I modify at
>>>>>>>> anytime during runtime a property e.g with just a text editor the bundle is
>>>>>>>> initiated again with the new property values which is a quite nice feature
>>>>>>>>
>>>>>>>> best
>>>>>>>>
>>>>>>>> Pablo
>>>>>>>>
>>>>>>>> On 12/07/2016 12:31 AM, David Jencks wrote:
>>>>>>>>
>>>>>>>> I’d like to make sure I understand what you are doing here…. IIUC
>>>>>>>> during the build of your project you are generating multiple configuration
>>>>>>>> files with the same or similar content, and each of these is loaded into a
>>>>>>>> configuration which is bound to a particular bundle location? So, at build
>>>>>>>> time you can change all the duplicate properties at once but if you need to
>>>>>>>> change them later you have to alter n (== number of duplicate configs)
>>>>>>>> independently? Whereas if you had multi-location support (and possibly
>>>>>>>> multi-pid support such as DS provides) you could share a single
>>>>>>>> Configuration and change the property while the framework was running in
>>>>>>>> one place?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <
>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>
>>>>>>>> Pablo,
>>>>>>>>
>>>>>>>> One possible solution to this problem that I'm currently looking at
>>>>>>>> is using a configuration bundle along with my features bundle. In the
>>>>>>>> configuration bundle I have all the cfg files and use properties
>>>>>>>> placeholders ${value} to set the value for key/value.
>>>>>>>>
>>>>>>>> In the POM I load properties files using the Maven properties
>>>>>>>> plugin and that lets me set a global set of properties values that can be
>>>>>>>> used in filling in the cfg values. So if a port or URI is shared across a
>>>>>>>> large number of them that automatically gets filled in. The features file
>>>>>>>> can then specify the cfg files to install and what name to install them
>>>>>>>> with.
>>>>>>>>
>>>>>>>> This gets rid of a lot of tedium and by using profiles I should be
>>>>>>>> able to switch dev, test and production, and have the properties
>>>>>>>> automatically set correctly.
>>>>>>>>
>>>>>>>> I'd like to modify this a bit so that dev, test and product cfg
>>>>>>>> files are all created simultaneously and simply installed in different
>>>>>>>> directories inside the configuration bundle. Then by using different
>>>>>>>> features installs I can easily switch between the different configurations
>>>>>>>> without having to tediously edit each configuration file.
>>>>>>>>
>>>>>>>> Brad
>>>>>>>>
>>>>>>>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Does Camel/Fuse even support DS? I haven't found any documentation
>>>>>>>>> saying otherwise. I've only found camel-scr which uses Felix-specific
>>>>>>>>> annotations and not DS.
>>>>>>>>>
>>>>>>>>> On 7 July 2016 at 14:32, Brad Johnson <
>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>
>>>>>>>>>> David,
>>>>>>>>>>
>>>>>>>>>> That is some pretty extreme and wild speculation alright. How
>>>>>>>>>> does one use blueprint to not use OSGi appropriately? In the 5 years I've
>>>>>>>>>> been consulting with Fuse/Karaf/OSGi and going to various clients not one
>>>>>>>>>> of them used or uses DS. Not one. They all use bundles, services, and
>>>>>>>>>> Camel with blueprint. The last time I worked with DS I didn't find it
>>>>>>>>>> provided any serious advantage and added another layer that I'd have to
>>>>>>>>>> teach my clients. Not that I wouldn't consider it or use it if I found a
>>>>>>>>>> real advantage but I haven't.
>>>>>>>>>>
>>>>>>>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in
>>>>>>>>>> OSGi 4.x land much less 5 or 6.
>>>>>>>>>>
>>>>>>>>>> So for Camel are you using the Java DSL?
>>>>>>>>>>
>>>>>>>>>> Brad
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <
>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you look
>>>>>>>>>>> at the osgi R5 or R6 config admin spec for “multi location”.
>>>>>>>>>>>
>>>>>>>>>>> You guys might be using blueprint every day, but there is no
>>>>>>>>>>> OSGI spec work to keep it up to date or even specify obviously necessary
>>>>>>>>>>> features such as config admin integration. If blueprint is so great why
>>>>>>>>>>> aren’t the proponents keeping the spec related to current OSGI? This is a
>>>>>>>>>>> part of my, admittedly extreme, theory that use of blueprint is related to
>>>>>>>>>>> not wanting to make the app actually use osgi appropriately.
>>>>>>>>>>>
>>>>>>>>>>> And, the project I work on every day uses DS exclusively and
>>>>>>>>>>> still finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>>>>>>>>>
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> It is in here;
>>>>>>>>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>>>>>>>>>
>>>>>>>>>>> A bundle is in aries bound to the pid. So it is actually working
>>>>>>>>>>> as expected, bit of
>>>>>>>>>>> a hassle since spring-dm allowed it.
>>>>>>>>>>>
>>>>>>>>>>> And yes selling DS into “regular" organizations is about as easy
>>>>>>>>>>> as selling snow in Alaska.
>>>>>>>>>>>
>>>>>>>>>>> /je
>>>>>>>>>>>
>>>>>>>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <
>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> David,
>>>>>>>>>>>
>>>>>>>>>>> You live in a very different world than I do. In all the
>>>>>>>>>>> consulting I do with Fuse/karaf blueprint is used almost exclusively. I
>>>>>>>>>>> understand DS and its uses but also its limits and overhead. It's like
>>>>>>>>>>> telling me one should only use Camel Java DSL. That may be one's
>>>>>>>>>>> perspective but that isn't everyone's.
>>>>>>>>>>>
>>>>>>>>>>> Brad
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <
>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> IMNSHO blueprint is only really plausible if you have a large
>>>>>>>>>>>> amount of Spring based code and you need to convert it to be sort of
>>>>>>>>>>>> osgi-compatible really quickly without understanding osgi or the code.
>>>>>>>>>>>> Otherwise taking the time to understand DS and use it is much more
>>>>>>>>>>>> satisfactory. DS provides this configuration override ability with support
>>>>>>>>>>>> for multiple pids, although only one of the pids can turn out to be a
>>>>>>>>>>>> factory configuration. There’s no obvious way of correlating factory
>>>>>>>>>>>> configurations, so this restriction makes some sense.
>>>>>>>>>>>>
>>>>>>>>>>>> I don’t think there really are any blueprint folks. The cm
>>>>>>>>>>>> stuff, while obviously required to make the spec remotely plausible, hasn’t
>>>>>>>>>>>> made it into the spec in the many many years it’s been sitting around.
>>>>>>>>>>>>
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <
>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> If I were to sit down with the blueprint folks today to create
>>>>>>>>>>>> a wish list one thing I'd like to see is for an ability to have a
>>>>>>>>>>>> configuration hierarchy specified with parent/child relationships much like
>>>>>>>>>>>> one has in Maven. Have a base configuration file and be able to have
>>>>>>>>>>>> another cfg file specify that one as its parent. Override properties or add
>>>>>>>>>>>> them to the child. When the configuration admin fires up it would read up
>>>>>>>>>>>> the chain and construct the properties.
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Ray,
>>>>>>>>>>>>>
>>>>>>>>>>>>> If I understand your question right the answer is the Aries
>>>>>>>>>>>>> extension is referencing configuration. In karaf/fuse for example the
>>>>>>>>>>>>> following:
>>>>>>>>>>>>>
>>>>>>>>>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>
>>>>>>>>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>>>>>>>>
>>>>>>>>>>>>> Installing that file is done either manually or by use of a
>>>>>>>>>>>>> features file.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Whenever I've attempted to use the PID in more than one bundle
>>>>>>>>>>>>> it has failed and I don't think it is permitted. That's a problem I think
>>>>>>>>>>>>> and something that should be fixed through some other configuration
>>>>>>>>>>>>> management mechanism. Making microservices that might share common
>>>>>>>>>>>>> properties, for example, becomes problematic in that regard and I've
>>>>>>>>>>>>> resorted to using my own OSGi services to overcome that problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Brad
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ok, so after a brief review the cm schema is an Aries
>>>>>>>>>>>>>> extension and it doesn't appear to support the location binding.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, it's unclear to me whether this extension is
>>>>>>>>>>>>>> creating the configuration or merely referencing one from outside.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any Aries gurus can answer that?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <
>>>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I’m not really familiar with blueprint cm but I’d expect
>>>>>>>>>>>>>>> that to indicate which pid to use to fetch the config from config admin and
>>>>>>>>>>>>>>> in the ... how to map configuration propertiething blueprint substitution
>>>>>>>>>>>>>>> knows about. Is that really instructions to create a new configuration and
>>>>>>>>>>>>>>> populate it with data (what a management agent does)?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <
>>>>>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> David, I agree with everything you've said, however this
>>>>>>>>>>>>>>> looks like blueprint being the agent here:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, blueprint cm shouldn’t really know about the
>>>>>>>>>>>>>>>> multi-location. The management agent that is creating the configuration
>>>>>>>>>>>>>>>> should be setting the bundle location to the multi-location ”?”.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I see and would it possible to configure which method is
>>>>>>>>>>>>>>>> invoked from Blueprint?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is how I do it:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> is there perhaps some blueprint property where I can tune
>>>>>>>>>>>>>>>> the second argument in the createFactoryConfiguration?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because it looks like the fact of using config admin
>>>>>>>>>>>>>>>> through blueprint binds the PID to the first bundle using it
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>>> Pablo
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As long as configurations are not bound to a bundle they
>>>>>>>>>>>>>>>> can be used by any bundle.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The exception clearly shows that the configuration is bound
>>>>>>>>>>>>>>>> to a bundle.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Creating an unbound configuration requires passing a "?" as
>>>>>>>>>>>>>>>> the second arguments to getConfiguration/createFactoryConfiguration methods
>>>>>>>>>>>>>>>> of CM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> HTH,
>>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Is it possible to use same config file from
>>>>>>>>>>>>>>>>>> multiple bundles while using Config Admin with blueprint Blueprint?
>>>>>>>>>>>>>>>>>> Because, I can't manage to do that, I get the following error:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No
>>>>>>>>>>>>>>>>>> visibility to configuration bound to
>>>>>>>>>>>>>>>>>> initial@reference:file:../plugin-2/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> However, I fear that this is a problem in the aries
>>>>>>>>>>>>>>>>>> blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>>>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As a workaround I can make a config file per bundle that
>>>>>>>>>>>>>>>>>> needs it....
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As follows the versions and bundles that I'm using
>>>>>>>>>>>>>>>>>> related to the container (Running on top of Equinox 3.11):
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support
>>>>>>>>>>>>>>>>>> for JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core
>>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>> Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API
>>>>>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>> Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM
>>>>>>>>>>>>>>>>>> (1.0.7)|1.0.7
>>>>>>>>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core
>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>>>> (1.5.0)|1.5.0
>>>>>>>>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>>>> Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed
>>>>>>>>>>>>>>>>>> Contexts (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API
>>>>>>>>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>> Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction
>>>>>>>>>>>>>>>>>> Blueprint (1.1.1)|1.1.1
>>>>>>>>>>>>>>>>>> 73|Active | 2|Aries JPA Container API
>>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for
>>>>>>>>>>>>>>>>>> Legacy Runtimes (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>>>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>> Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>> provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation
>>>>>>>>>>>>>>>>>> API (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction
>>>>>>>>>>>>>>>>>> Blueprint (2.1.0)|2.1.0
>>>>>>>>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation
>>>>>>>>>>>>>>>>>> Impl (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>> Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>>> Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service
>>>>>>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic
>>>>>>>>>>>>>>>>>> Weaving Bundle (1.0.8)|1.0.8
>>>>>>>>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint
>>>>>>>>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 11|Active | 4|Apache Felix File Install
>>>>>>>>>>>>>>>>>> (3.5.4)|3.5.4
>>>>>>>>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell
>>>>>>>>>>>>>>>>>> (0.12.0)|0.12.0
>>>>>>>>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command
>>>>>>>>>>>>>>>>>> (0.16.0)|0.16.0
>>>>>>>>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime
>>>>>>>>>>>>>>>>>> (0.16.2)|0.16.2
>>>>>>>>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management
>>>>>>>>>>>>>>>>>> Console (1.2.8)|1.2.8
>>>>>>>>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin
>>>>>>>>>>>>>>>>>> Service (1.8.8)|1.8.8
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email.
>>>>>>>>>>>>>>>>>> The recipient should check this email and any attachments for the presence
>>>>>>>>>>>>>>>>>> of viruses. The company accepts no liability for any damage caused by any
>>>>>>>>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>>>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>>>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>>>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Warning: Although the company has taken reasonable
>>>>>>>>>>>>>>>>>> precautions to ensure no viruses are present in this email, the company
>>>>>>>>>>>>>>>>>> cannot accept responsibility for any loss or damage arising from the use of
>>>>>>>>>>>>>>>>>> this email or attachments.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Red Hat, Open Source Integration
>>>>>
>>>>> Email: gnodet@redhat.com
>>>>> Web: http://fusesource.com
>>>>> Blog: http://gnodet.blogspot.com/
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
I'd thought that it was possible since the examples have a SimpleRegistry
and mention using it to register beans. But when I looked at the
AbstractCamelRunner it became obvious that that would not work.
I'm trying something by creating a new SCRRegistry type just for the sake
of experimentation. Internally it has a CompositeRegistry and the
AbstractCamelRunner which I'm modifying uses the new SCRRegistry which has
a setter or on it for both a SimpleRegistry and an OsgiRegistry. If it
finds the bundle context it creates the OSGi service registry and adds it
and in either case adds a SimpleRegistry after it.
protected void createCamelContext(final BundleContext bundleContext,
final Map<String, String> props) {
if (bundleContext != null) {
OsgiServiceRegistry osgiRegistry = new
OsgiServiceRegistry(bundleContext);
context = new OsgiDefaultCamelContext(bundleContext,
osgiRegistry);
// Setup the application context classloader with the bundle
classloader
context.setApplicationContextClassLoader(new
BundleDelegatingClassLoader(bundleContext.getBundle()));
// and make sure the TCCL is our classloader
Thread.currentThread().setContextClassLoader(context.getApplicationContextClassLoader());
this.registry.setOsgiRegistry(osgiRegistry);
}
registry.setSimpleRegistry(new SimpleRegistry());
context = new DefaultCamelContext(registry);
Inside the SCRRegistry it delegates all its Registry interface calls to the
CompositeRegistry but it keeps a handle on the SimpleRegistry. So to
register a class one can do the following:
registry.register(POValidator.class);
In this case it's very simple instantiation of the no-arg constructor and
then looking for EndpointInject annotations and setting it to the
ProducerTemplate and the URI it finds. This is such a quick and naive cut
that I'm not even checking to see if there's an endpoint by that name in
the registry already which I could just use instead. Obviously if I do
anything more with this I'll look at reusing the existing libraries for
annotation processing instead of writing this stuff by hand. I still
haven't tested this by throwing it in karaf with Felix or any other OSGi
implementation.
public void register(Class clazz){
try {
Object o=clazz.newInstance();
for(Field declaredField:clazz.getDeclaredFields())
{
for(EndpointInject endpoint:
declaredField.getAnnotationsByType(EndpointInject.class))
{
declaredField.setAccessible(true);
ProducerTemplate template = camelContext.createProducerTemplate();
template.setDefaultEndpointUri(endpoint.uri());
declaredField.set(o,template);
}
}
this.simpleRegistry.put(clazz.getSimpleName(), o);
} catch (InstantiationException | IllegalAccessException e) {
//TODO log..
}
}
On Mon, Aug 1, 2016 at 6:33 PM, Matt Sicker <bo...@gmail.com> wrote:
> Can you even make a semi-private service in DS/SCR? What could the
> equivalent be to a blueprint bean that isn't exported as a service? Or is
> the philosophy to make all services public in DS?
>
> On 1 August 2016 at 18:12, Brad Johnson <br...@mediadriver.com>
> wrote:
>
>> Tim,
>>
>> After working with DS and SCR a little I can understand its benefits.
>> One obvious advantage was being able to write basic JUnit tests to test my
>> routes without having to fire up CBTS. I've always disliked working in XML
>> so it is odd being in the position like I sound like I'm the one
>> championing it.
>>
>> The main problem right now with Camel is that while SCR handles all the
>> external items there isn't a way to do any injection of "local"
>> dependencies. By that I mean within my own bundle I might have validators,
>> handlers, local data models, etc. that I want to stand up and run in my
>> Camel routes. Camel SCR doesn't have a mechanism for doing that.
>>
>> When one runs it locally in the IDE it fires up a SimpleRegistry and uses
>> that to register everything and in that case you can manually add your own
>> beans before setting up route definitions. If the bundle is running where
>> it has a bundle context it instead fires up an OsgiServiceRegistry(don't
>> recall the full name.) In that case you can't add your local beans.
>>
>> I noted that there is a CompositeRegistry in the AbstractCamelRunner and
>> perhaps that should always be the one used. If one boots up and an OSGi
>> service registry is created both it and the SimpleRegistry are added to the
>> CompositeRegistry but one can access the SimpleRegistry in order to add
>> one's local dependencies for Camel routes.
>>
>> On Wed, Jul 13, 2016 at 3:34 AM, Timothy Ward <ti...@apache.org>
>> wrote:
>>
>>> Hi Brad,
>>>
>>> I’ve been watching this thread for a while, and you’ve finally managed
>>> to draw me in :)
>>>
>>>
>>> On 12 Jul 2016, at 17:42, Brad Johnson <br...@mediadriver.com>
>>> wrote:
>>>
>>> Guillaume,
>>>
>>> I'm still using Blueprint and have found Camel/SCR to be a pain to work
>>> with. It provides no tangible benefit if one is using Blueprint for routes
>>> and dependency injection anyway as it simply introduces one more way of
>>> configuring things. It was interesting to read the other day that Christian
>>> seems to have the same impression of the complexity of SCR. I remember
>>> when I first tried I thought it looked pretty cool but started running into
>>> problems.
>>>
>>>
>>> So what you’re comparing here isn’t really apples with apples. A long
>>> way back Camel provided a bunch of Spring XML sugar to make configuring
>>> Camel simpler. This was obviously a good thing because setting up Camel was
>>> (and is) hard. To this day people still use the Spring syntax for building
>>> their Camel routes. OSGi blueprint was effectively a move by Spring to
>>> standardise the Spring DM container, and so unsurprisingly blueprint looks
>>> a lot like Spring. Some people did the work to port the Camel Spring
>>> configuration to OSGi blueprint, and that’s why Camel is easy to use in
>>> blueprint.
>>>
>>> If someone actually spent some time putting together a nice integration
>>> with SCR then I’m sure that using SCR would be at least as easy as
>>> blueprint. The problem here is that relatively few SCR developers/users use
>>> Camel, and the ones that do are just told to “use blueprint”.
>>>
>>> That DS is in its second generation and only now getting around to
>>> transactions is telling. Either it has reached its natural boundaries and
>>> is now over-reaching or wasn’t full thought out.
>>>
>>>
>>> DS is actually working on its fifth release, and transactions are
>>> nowhere to be seen. You may be referring to the Transaction Control
>>> specification, which is separate from DS. They can be used together very
>>> effectively, but you could equally use Transaction Control with blueprint.
>>>
>>> DS is actually one of the “good citizens” of the DI world in that it
>>> deliberately does less in order to do it well. There’s no dependency
>>> proxying, no aspects, just the code that you wrote injected with some other
>>> code that someone wrote.
>>>
>>> To me it's a component and service bootstrapping mechanism which
>>> represents a small portion of the world I work in - transforms, routing,
>>> EIPs, etc. I've no reason to embrace it or deny it unless it either makes
>>> my job much easier or I can't live without it. So far adding Camel SCR and
>>> DS into the middleware just results in one more thing I have to deal with.
>>>
>>>
>>> This is a perfectly acceptable viewpoint. If the fundamental limitations
>>> of the blueprint model aren’t a problem for you then switching right now is
>>> almost certainly unnecessary.
>>>
>>>
>>> I think Blueprint works well these days and has come a long way in the
>>> past 3 years. The Aries team is to be commended for some great work.
>>>
>>>
>>> Aries Blueprint has had a lot of extensions and improvements over the
>>> last three years. Sadly the same cannot be said for the specifications or
>>> other implementations. Aries Blueprint is very much the last implementation
>>> standing, and there has been no effort to standardise the new features (or
>>> even to try fixing the problems with the original standard). The set of
>>> RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance is
>>> very telling.
>>>
>>> As far as Aries blueprint is concerned, the main reason that it is still
>>> alive seems to be the fact that it was included in Karaf, and that Karaf
>>> provides Camel integration alongside it. Even Karaf itself is starting to
>>> move to use DS internally, offering blueprint as something for applications
>>> to use.
>>>
>>>
>>> I’ve been surprised by the near religious zeal of some of the DS
>>> advocates.
>>>
>>>
>>> Most OSGi developers I know (myself included) who really start to use DS
>>> consider it to be roughly equivalent to magic. The fact that the model can
>>> be as simple as it is and yet still flexible, correct and safe is both
>>> surprising and pleasing. Moving back to “not DS” is usually pretty painful
>>> and reminds people why they love DS so much.
>>>
>>> I'll be interested in seeing the DS semantics and proxies for CDI. Heh.
>>> Proxies are another technology that I don't care about one way or the other
>>> as long as things work well and don't require a lot of configuration. So
>>> it’s great if we can get rid of proxies but not so great if I now have to
>>> trade that off for configuration of start up order on services to make sure
>>> everything is running before Camel routes come up.
>>>
>>>
>>> Actually, this is one of the places where DS really shines. If you write
>>> a DS component properly (i.e. without trying to dig out of the DS
>>> lifecycle) then startup ordering ceases to be an issue.
>>>
>>> Again, someone with a little time and expertise would probably find that
>>> Camel + DS can be a really effective solution. The problem is finding the
>>> person who has the time, expertise and inclination…
>>>
>>> Tim Ward
>>>
>>> Apache Aries PMC Member,
>>> OSGi IoT Expert Group Chair,
>>> Author Enterprise OSGi in Action
>>> timothyjward@apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gn...@apache.org>
>>> wrote:
>>>
>>>> I can happily review a patch if you're fancy writing one...
>>>>
>>>> And I disagree with the 'blueprint is dead and nobody cares about it
>>>> anymore'. What's dead is the blueprint osgi specification for blueprint,
>>>> not the Aries Blueprint project. I've recently added a bunch of important
>>>> features related to spring in blueprint.
>>>>
>>>> DS also has some drawbacks as it's not extensible at all : this is
>>>> leading the OSGi Alliance to write a new spec for transaction support !!!
>>>>
>>>> I think the CDI+DS extension I've been working on those past weeks
>>>> could bring the best of both world : strong DS semantics for the OSGi bits,
>>>> but extensibility and support for proxies provided by CDI ;-)
>>>>
>>>>
>>>> 2016-07-12 17:24 GMT+02:00 Brad Johnson <br...@mediadriver.com>:
>>>>
>>>>> David,
>>>>>
>>>>> I'm all for multilocation support in blueprint. Can't wait for it.
>>>>> But it sounds like your saying blueprint is dead and nobody cares about it
>>>>> anymore so it doesn't seem likely to happen anytime soon. It certainly
>>>>> wouldn't be relevant to Fuse which uses R4 in any case.
>>>>>
>>>>> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <
>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>
>>>>>> The features file can have statements like this:
>>>>>>
>>>>>>
>>>>>> <configfile finalname="/etc/com.foo.cfg"
>>>>>> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
>>>>>> <configfile finalname="/etc/com.bar.cfg"
>>>>>> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
>>>>>> ....etc....
>>>>>> That's off the top of my head so take it with a grain of salt for
>>>>>> syntax.
>>>>>>
>>>>>> When you run the features install it will overwrite the files in the
>>>>>> etc directory with the ones in the maven bundle which have now been
>>>>>> updated. So instead of modifying configuration files in the etc directory
>>>>>> you modifying them in your Maven configuration project and recompile the
>>>>>> bundle and then pull it from the repo
>>>>>> in order to update the values.
>>>>>>
>>>>>> But you can still modify them in the etc if you wanted. You just have
>>>>>> to make sure you have the cm properties set to reload.
>>>>>>
>>>>>> <cm:property-placeholder persistent-id="com.foo"
>>>>>> update-strategy="reload">
>>>>>>
>>>>>> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <
>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>
>>>>>>> Brad, if I understand your approach too that would lead to not being
>>>>>>> able to dynamically change common properties in a single config place
>>>>>>> during runtime, as the fill made by maven would be only done once at build
>>>>>>> time right? But at runtime I would need to that as David mention, still n
>>>>>>> times right?
>>>>>>>
>>>>>>> as a use case for instance, with blueprint:cm update-strategy
>>>>>>> configured as 'reload' in combination with felix-fileinstall as directory
>>>>>>> watcher, bundles are reloaded automatically so that when I modify at
>>>>>>> anytime during runtime a property e.g with just a text editor the bundle is
>>>>>>> initiated again with the new property values which is a quite nice feature
>>>>>>>
>>>>>>> best
>>>>>>>
>>>>>>> Pablo
>>>>>>>
>>>>>>> On 12/07/2016 12:31 AM, David Jencks wrote:
>>>>>>>
>>>>>>> I’d like to make sure I understand what you are doing here…. IIUC
>>>>>>> during the build of your project you are generating multiple configuration
>>>>>>> files with the same or similar content, and each of these is loaded into a
>>>>>>> configuration which is bound to a particular bundle location? So, at build
>>>>>>> time you can change all the duplicate properties at once but if you need to
>>>>>>> change them later you have to alter n (== number of duplicate configs)
>>>>>>> independently? Whereas if you had multi-location support (and possibly
>>>>>>> multi-pid support such as DS provides) you could share a single
>>>>>>> Configuration and change the property while the framework was running in
>>>>>>> one place?
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <
>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>
>>>>>>> Pablo,
>>>>>>>
>>>>>>> One possible solution to this problem that I'm currently looking at
>>>>>>> is using a configuration bundle along with my features bundle. In the
>>>>>>> configuration bundle I have all the cfg files and use properties
>>>>>>> placeholders ${value} to set the value for key/value.
>>>>>>>
>>>>>>> In the POM I load properties files using the Maven properties plugin
>>>>>>> and that lets me set a global set of properties values that can be used in
>>>>>>> filling in the cfg values. So if a port or URI is shared across a large
>>>>>>> number of them that automatically gets filled in. The features file can
>>>>>>> then specify the cfg files to install and what name to install them with.
>>>>>>>
>>>>>>> This gets rid of a lot of tedium and by using profiles I should be
>>>>>>> able to switch dev, test and production, and have the properties
>>>>>>> automatically set correctly.
>>>>>>>
>>>>>>> I'd like to modify this a bit so that dev, test and product cfg
>>>>>>> files are all created simultaneously and simply installed in different
>>>>>>> directories inside the configuration bundle. Then by using different
>>>>>>> features installs I can easily switch between the different configurations
>>>>>>> without having to tediously edit each configuration file.
>>>>>>>
>>>>>>> Brad
>>>>>>>
>>>>>>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Does Camel/Fuse even support DS? I haven't found any documentation
>>>>>>>> saying otherwise. I've only found camel-scr which uses Felix-specific
>>>>>>>> annotations and not DS.
>>>>>>>>
>>>>>>>> On 7 July 2016 at 14:32, Brad Johnson <brad.johnson@mediadriver.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> David,
>>>>>>>>>
>>>>>>>>> That is some pretty extreme and wild speculation alright. How
>>>>>>>>> does one use blueprint to not use OSGi appropriately? In the 5 years I've
>>>>>>>>> been consulting with Fuse/Karaf/OSGi and going to various clients not one
>>>>>>>>> of them used or uses DS. Not one. They all use bundles, services, and
>>>>>>>>> Camel with blueprint. The last time I worked with DS I didn't find it
>>>>>>>>> provided any serious advantage and added another layer that I'd have to
>>>>>>>>> teach my clients. Not that I wouldn't consider it or use it if I found a
>>>>>>>>> real advantage but I haven't.
>>>>>>>>>
>>>>>>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in
>>>>>>>>> OSGi 4.x land much less 5 or 6.
>>>>>>>>>
>>>>>>>>> So for Camel are you using the Java DSL?
>>>>>>>>>
>>>>>>>>> Brad
>>>>>>>>>
>>>>>>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <
>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you look
>>>>>>>>>> at the osgi R5 or R6 config admin spec for “multi location”.
>>>>>>>>>>
>>>>>>>>>> You guys might be using blueprint every day, but there is no OSGI
>>>>>>>>>> spec work to keep it up to date or even specify obviously necessary
>>>>>>>>>> features such as config admin integration. If blueprint is so great why
>>>>>>>>>> aren’t the proponents keeping the spec related to current OSGI? This is a
>>>>>>>>>> part of my, admittedly extreme, theory that use of blueprint is related to
>>>>>>>>>> not wanting to make the app actually use osgi appropriately.
>>>>>>>>>>
>>>>>>>>>> And, the project I work on every day uses DS exclusively and
>>>>>>>>>> still finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>>>>>>>>
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> It is in here;
>>>>>>>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>>>>>>>>
>>>>>>>>>> A bundle is in aries bound to the pid. So it is actually working
>>>>>>>>>> as expected, bit of
>>>>>>>>>> a hassle since spring-dm allowed it.
>>>>>>>>>>
>>>>>>>>>> And yes selling DS into “regular" organizations is about as easy
>>>>>>>>>> as selling snow in Alaska.
>>>>>>>>>>
>>>>>>>>>> /je
>>>>>>>>>>
>>>>>>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <
>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>
>>>>>>>>>> David,
>>>>>>>>>>
>>>>>>>>>> You live in a very different world than I do. In all the
>>>>>>>>>> consulting I do with Fuse/karaf blueprint is used almost exclusively. I
>>>>>>>>>> understand DS and its uses but also its limits and overhead. It's like
>>>>>>>>>> telling me one should only use Camel Java DSL. That may be one's
>>>>>>>>>> perspective but that isn't everyone's.
>>>>>>>>>>
>>>>>>>>>> Brad
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <
>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> IMNSHO blueprint is only really plausible if you have a large
>>>>>>>>>>> amount of Spring based code and you need to convert it to be sort of
>>>>>>>>>>> osgi-compatible really quickly without understanding osgi or the code.
>>>>>>>>>>> Otherwise taking the time to understand DS and use it is much more
>>>>>>>>>>> satisfactory. DS provides this configuration override ability with support
>>>>>>>>>>> for multiple pids, although only one of the pids can turn out to be a
>>>>>>>>>>> factory configuration. There’s no obvious way of correlating factory
>>>>>>>>>>> configurations, so this restriction makes some sense.
>>>>>>>>>>>
>>>>>>>>>>> I don’t think there really are any blueprint folks. The cm
>>>>>>>>>>> stuff, while obviously required to make the spec remotely plausible, hasn’t
>>>>>>>>>>> made it into the spec in the many many years it’s been sitting around.
>>>>>>>>>>>
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <
>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> If I were to sit down with the blueprint folks today to create a
>>>>>>>>>>> wish list one thing I'd like to see is for an ability to have a
>>>>>>>>>>> configuration hierarchy specified with parent/child relationships much like
>>>>>>>>>>> one has in Maven. Have a base configuration file and be able to have
>>>>>>>>>>> another cfg file specify that one as its parent. Override properties or add
>>>>>>>>>>> them to the child. When the configuration admin fires up it would read up
>>>>>>>>>>> the chain and construct the properties.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Ray,
>>>>>>>>>>>>
>>>>>>>>>>>> If I understand your question right the answer is the Aries
>>>>>>>>>>>> extension is referencing configuration. In karaf/fuse for example the
>>>>>>>>>>>> following:
>>>>>>>>>>>>
>>>>>>>>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>
>>>>>>>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>>>>>>>
>>>>>>>>>>>> Installing that file is done either manually or by use of a
>>>>>>>>>>>> features file.
>>>>>>>>>>>>
>>>>>>>>>>>> Whenever I've attempted to use the PID in more than one bundle
>>>>>>>>>>>> it has failed and I don't think it is permitted. That's a problem I think
>>>>>>>>>>>> and something that should be fixed through some other configuration
>>>>>>>>>>>> management mechanism. Making microservices that might share common
>>>>>>>>>>>> properties, for example, becomes problematic in that regard and I've
>>>>>>>>>>>> resorted to using my own OSGi services to overcome that problem.
>>>>>>>>>>>>
>>>>>>>>>>>> Brad
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Ok, so after a brief review the cm schema is an Aries
>>>>>>>>>>>>> extension and it doesn't appear to support the location binding.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, it's unclear to me whether this extension is creating
>>>>>>>>>>>>> the configuration or merely referencing one from outside.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any Aries gurus can answer that?
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <
>>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I’m not really familiar with blueprint cm but I’d expect that
>>>>>>>>>>>>>> to indicate which pid to use to fetch the config from config admin and in
>>>>>>>>>>>>>> the ... how to map configuration propertiething blueprint substitution
>>>>>>>>>>>>>> knows about. Is that really instructions to create a new configuration and
>>>>>>>>>>>>>> populate it with data (what a management agent does)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <
>>>>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David, I agree with everything you've said, however this
>>>>>>>>>>>>>> looks like blueprint being the agent here:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, blueprint cm shouldn’t really know about the
>>>>>>>>>>>>>>> multi-location. The management agent that is creating the configuration
>>>>>>>>>>>>>>> should be setting the bundle location to the multi-location ”?”.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I see and would it possible to configure which method is
>>>>>>>>>>>>>>> invoked from Blueprint?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is how I do it:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is there perhaps some blueprint property where I can tune
>>>>>>>>>>>>>>> the second argument in the createFactoryConfiguration?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because it looks like the fact of using config admin through
>>>>>>>>>>>>>>> blueprint binds the PID to the first bundle using it
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>> Pablo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As long as configurations are not bound to a bundle they can
>>>>>>>>>>>>>>> be used by any bundle.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The exception clearly shows that the configuration is bound
>>>>>>>>>>>>>>> to a bundle.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Creating an unbound configuration requires passing a "?" as
>>>>>>>>>>>>>>> the second arguments to getConfiguration/createFactoryConfiguration methods
>>>>>>>>>>>>>>> of CM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> HTH,
>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Is it possible to use same config file from
>>>>>>>>>>>>>>>>> multiple bundles while using Config Admin with blueprint Blueprint?
>>>>>>>>>>>>>>>>> Because, I can't manage to do that, I get the following error:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No
>>>>>>>>>>>>>>>>> visibility to configuration bound to
>>>>>>>>>>>>>>>>> initial@reference:file:../plugin-2/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> However, I fear that this is a problem in the aries
>>>>>>>>>>>>>>>>> blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As a workaround I can make a config file per bundle that
>>>>>>>>>>>>>>>>> needs it....
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As follows the versions and bundles that I'm using related
>>>>>>>>>>>>>>>>> to the container (Running on top of Equinox 3.11):
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support
>>>>>>>>>>>>>>>>> for JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core
>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>> Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>> Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM
>>>>>>>>>>>>>>>>> (1.0.7)|1.0.7
>>>>>>>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>>> (1.5.0)|1.5.0
>>>>>>>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>>> Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed
>>>>>>>>>>>>>>>>> Contexts (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API
>>>>>>>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service
>>>>>>>>>>>>>>>>> Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>>>>>>> (1.1.1)|1.1.1
>>>>>>>>>>>>>>>>> 73|Active | 2|Aries JPA Container API
>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for
>>>>>>>>>>>>>>>>> Legacy Runtimes (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>> Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>> provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation
>>>>>>>>>>>>>>>>> API (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>>>>>>> (2.1.0)|2.1.0
>>>>>>>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation
>>>>>>>>>>>>>>>>> Impl (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>> Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>> Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service
>>>>>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic
>>>>>>>>>>>>>>>>> Weaving Bundle (1.0.8)|1.0.8
>>>>>>>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint
>>>>>>>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 11|Active | 4|Apache Felix File Install
>>>>>>>>>>>>>>>>> (3.5.4)|3.5.4
>>>>>>>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell
>>>>>>>>>>>>>>>>> (0.12.0)|0.12.0
>>>>>>>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command
>>>>>>>>>>>>>>>>> (0.16.0)|0.16.0
>>>>>>>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime
>>>>>>>>>>>>>>>>> (0.16.2)|0.16.2
>>>>>>>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management
>>>>>>>>>>>>>>>>> Console (1.2.8)|1.2.8
>>>>>>>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin
>>>>>>>>>>>>>>>>> Service (1.8.8)|1.8.8
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email.
>>>>>>>>>>>>>>>>> The recipient should check this email and any attachments for the presence
>>>>>>>>>>>>>>>>> of viruses. The company accepts no liability for any damage caused by any
>>>>>>>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Warning: Although the company has taken reasonable
>>>>>>>>>>>>>>>>> precautions to ensure no viruses are present in this email, the company
>>>>>>>>>>>>>>>>> cannot accept responsibility for any loss or damage arising from the use of
>>>>>>>>>>>>>>>>> this email or attachments.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Red Hat, Open Source Integration
>>>>
>>>> Email: gnodet@redhat.com
>>>> Web: http://fusesource.com
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>>>
>>>
>>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
David, (for some reason Google was filtering your email address from yahoo
as a phishing attack)
I agree and think that DS and the SCR are great for exposing and importing
services. In Blueprint I'd use the normal service/reference mechanics in
XML for that but can easily jettison it. But most of the work I do isn't
involved with inter-bundle service communication. And even there the
communications can be via Camel endpoints. The OSGi services I use are
usually for true cross-cutting concerns that wouldn't be remote.
But Camel SCR simply doesn't have a way to use any internal wiring of beans
and routes. Even when I do expose services via the OSGi registry it might
be for transforming canonical models into specific forms and back again.
So I need to load up Dozer mapping, get a method call, route to the
transform and send the results back with validators and exception handlers
and logging interceptors all along those internal routes. To the outside
user they are just calling an interface method of FooInventory
convert(InventoryCanonical model) and all the dependencies, mappings, etc.
remain encapsulated in the bundle that exports that interface. But there's
a lot of internal wiring. And that's a relatively simple example.
But Camel SCR doesn't make that really available.
On Mon, Aug 1, 2016 at 7:22 PM, David Jencks <da...@yahoo.com> wrote:
> if the declared DS services are non-exported classes in the bundle then
> even though it gets in the service registry it won’t be accessible outside
> the bundle.
> You can also use a non-feature subsystem to restrict visibility to the
> service, but that starts getting complicated pretty rapidly.
> If you are even more ambitions you can use the Region api that is used in
> back of the subsystem implementation or if you are foolhardy you can use
> framework service hooks for the same purpose.
>
> However…. DS is not really intended to be a universal wiring framework for
> everything. It’s intended to provide a really good way to set up
> configured OSGI services. Once you start wanting private components I
> start wondering if the component is actually appropriate to be exposed as a
> service.
>
> I would be interested in seeing something like this in xml form with an
> indication of what kind of wiring variability is needed or useful. I’d
> like to understand how much independent configuration there is, how it
> would be most logically grouped, and how much the wiring could just as well
> be written in java. I’m wondering about an approach of having basically
> one DS component that gets the configuration(s) and wires up the other
> components somehow.
>
> thanks
> david jencks
>
> On Aug 1, 2016, at 4:33 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Can you even make a semi-private service in DS/SCR? What could the
> equivalent be to a blueprint bean that isn't exported as a service? Or is
> the philosophy to make all services public in DS?
>
> On 1 August 2016 at 18:12, Brad Johnson <br...@mediadriver.com>
> wrote:
>
>> Tim,
>>
>> After working with DS and SCR a little I can understand its benefits.
>> One obvious advantage was being able to write basic JUnit tests to test my
>> routes without having to fire up CBTS. I've always disliked working in XML
>> so it is odd being in the position like I sound like I'm the one
>> championing it.
>>
>> The main problem right now with Camel is that while SCR handles all the
>> external items there isn't a way to do any injection of "local"
>> dependencies. By that I mean within my own bundle I might have validators,
>> handlers, local data models, etc. that I want to stand up and run in my
>> Camel routes. Camel SCR doesn't have a mechanism for doing that.
>>
>> When one runs it locally in the IDE it fires up a SimpleRegistry and uses
>> that to register everything and in that case you can manually add your own
>> beans before setting up route definitions. If the bundle is running where
>> it has a bundle context it instead fires up an OsgiServiceRegistry(don't
>> recall the full name.) In that case you can't add your local beans.
>>
>> I noted that there is a CompositeRegistry in the AbstractCamelRunner and
>> perhaps that should always be the one used. If one boots up and an OSGi
>> service registry is created both it and the SimpleRegistry are added to the
>> CompositeRegistry but one can access the SimpleRegistry in order to add
>> one's local dependencies for Camel routes.
>>
>> On Wed, Jul 13, 2016 at 3:34 AM, Timothy Ward <ti...@apache.org>
>> wrote:
>>
>>> Hi Brad,
>>>
>>> I’ve been watching this thread for a while, and you’ve finally managed
>>> to draw me in :)
>>>
>>>
>>> On 12 Jul 2016, at 17:42, Brad Johnson <br...@mediadriver.com>
>>> wrote:
>>>
>>> Guillaume,
>>>
>>> I'm still using Blueprint and have found Camel/SCR to be a pain to work
>>> with. It provides no tangible benefit if one is using Blueprint for routes
>>> and dependency injection anyway as it simply introduces one more way of
>>> configuring things. It was interesting to read the other day that Christian
>>> seems to have the same impression of the complexity of SCR. I remember
>>> when I first tried I thought it looked pretty cool but started running into
>>> problems.
>>>
>>>
>>> So what you’re comparing here isn’t really apples with apples. A long
>>> way back Camel provided a bunch of Spring XML sugar to make configuring
>>> Camel simpler. This was obviously a good thing because setting up Camel was
>>> (and is) hard. To this day people still use the Spring syntax for building
>>> their Camel routes. OSGi blueprint was effectively a move by Spring to
>>> standardise the Spring DM container, and so unsurprisingly blueprint looks
>>> a lot like Spring. Some people did the work to port the Camel Spring
>>> configuration to OSGi blueprint, and that’s why Camel is easy to use in
>>> blueprint.
>>>
>>> If someone actually spent some time putting together a nice integration
>>> with SCR then I’m sure that using SCR would be at least as easy as
>>> blueprint. The problem here is that relatively few SCR developers/users use
>>> Camel, and the ones that do are just told to “use blueprint”.
>>>
>>> That DS is in its second generation and only now getting around to
>>> transactions is telling. Either it has reached its natural boundaries and
>>> is now over-reaching or wasn’t full thought out.
>>>
>>>
>>> DS is actually working on its fifth release, and transactions are
>>> nowhere to be seen. You may be referring to the Transaction Control
>>> specification, which is separate from DS. They can be used together very
>>> effectively, but you could equally use Transaction Control with blueprint.
>>>
>>> DS is actually one of the “good citizens” of the DI world in that it
>>> deliberately does less in order to do it well. There’s no dependency
>>> proxying, no aspects, just the code that you wrote injected with some other
>>> code that someone wrote.
>>>
>>> To me it's a component and service bootstrapping mechanism which
>>> represents a small portion of the world I work in - transforms, routing,
>>> EIPs, etc. I've no reason to embrace it or deny it unless it either makes
>>> my job much easier or I can't live without it. So far adding Camel SCR and
>>> DS into the middleware just results in one more thing I have to deal with.
>>>
>>>
>>> This is a perfectly acceptable viewpoint. If the fundamental limitations
>>> of the blueprint model aren’t a problem for you then switching right now is
>>> almost certainly unnecessary.
>>>
>>>
>>> I think Blueprint works well these days and has come a long way in the
>>> past 3 years. The Aries team is to be commended for some great work.
>>>
>>>
>>> Aries Blueprint has had a lot of extensions and improvements over the
>>> last three years. Sadly the same cannot be said for the specifications or
>>> other implementations. Aries Blueprint is very much the last implementation
>>> standing, and there has been no effort to standardise the new features (or
>>> even to try fixing the problems with the original standard). The set of
>>> RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance is
>>> very telling.
>>>
>>> As far as Aries blueprint is concerned, the main reason that it is still
>>> alive seems to be the fact that it was included in Karaf, and that Karaf
>>> provides Camel integration alongside it. Even Karaf itself is starting to
>>> move to use DS internally, offering blueprint as something for applications
>>> to use.
>>>
>>>
>>> I’ve been surprised by the near religious zeal of some of the DS
>>> advocates.
>>>
>>>
>>> Most OSGi developers I know (myself included) who really start to use DS
>>> consider it to be roughly equivalent to magic. The fact that the model can
>>> be as simple as it is and yet still flexible, correct and safe is both
>>> surprising and pleasing. Moving back to “not DS” is usually pretty painful
>>> and reminds people why they love DS so much.
>>>
>>> I'll be interested in seeing the DS semantics and proxies for CDI. Heh.
>>> Proxies are another technology that I don't care about one way or the other
>>> as long as things work well and don't require a lot of configuration. So
>>> it’s great if we can get rid of proxies but not so great if I now have to
>>> trade that off for configuration of start up order on services to make sure
>>> everything is running before Camel routes come up.
>>>
>>>
>>> Actually, this is one of the places where DS really shines. If you write
>>> a DS component properly (i.e. without trying to dig out of the DS
>>> lifecycle) then startup ordering ceases to be an issue.
>>>
>>> Again, someone with a little time and expertise would probably find that
>>> Camel + DS can be a really effective solution. The problem is finding the
>>> person who has the time, expertise and inclination…
>>>
>>> Tim Ward
>>>
>>> Apache Aries PMC Member,
>>> OSGi IoT Expert Group Chair,
>>> Author Enterprise OSGi in Action
>>> timothyjward@apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gn...@apache.org>
>>> wrote:
>>>
>>>> I can happily review a patch if you're fancy writing one...
>>>>
>>>> And I disagree with the 'blueprint is dead and nobody cares about it
>>>> anymore'. What's dead is the blueprint osgi specification for blueprint,
>>>> not the Aries Blueprint project. I've recently added a bunch of important
>>>> features related to spring in blueprint.
>>>>
>>>> DS also has some drawbacks as it's not extensible at all : this is
>>>> leading the OSGi Alliance to write a new spec for transaction support !!!
>>>>
>>>> I think the CDI+DS extension I've been working on those past weeks
>>>> could bring the best of both world : strong DS semantics for the OSGi bits,
>>>> but extensibility and support for proxies provided by CDI ;-)
>>>>
>>>>
>>>> 2016-07-12 17:24 GMT+02:00 Brad Johnson <br...@mediadriver.com>:
>>>>
>>>>> David,
>>>>>
>>>>> I'm all for multilocation support in blueprint. Can't wait for it.
>>>>> But it sounds like your saying blueprint is dead and nobody cares about it
>>>>> anymore so it doesn't seem likely to happen anytime soon. It certainly
>>>>> wouldn't be relevant to Fuse which uses R4 in any case.
>>>>>
>>>>> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <
>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>
>>>>>> The features file can have statements like this:
>>>>>>
>>>>>>
>>>>>> <configfile finalname="/etc/com.foo.cfg"
>>>>>> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
>>>>>> <configfile finalname="/etc/com.bar.cfg"
>>>>>> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
>>>>>> ....etc....
>>>>>> That's off the top of my head so take it with a grain of salt for
>>>>>> syntax.
>>>>>>
>>>>>> When you run the features install it will overwrite the files in the
>>>>>> etc directory with the ones in the maven bundle which have now been
>>>>>> updated. So instead of modifying configuration files in the etc directory
>>>>>> you modifying them in your Maven configuration project and recompile the
>>>>>> bundle and then pull it from the repo
>>>>>> in order to update the values.
>>>>>>
>>>>>> But you can still modify them in the etc if you wanted. You just have
>>>>>> to make sure you have the cm properties set to reload.
>>>>>>
>>>>>> <cm:property-placeholder persistent-id="com.foo"
>>>>>> update-strategy="reload">
>>>>>>
>>>>>> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <
>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>
>>>>>>> Brad, if I understand your approach too that would lead to not being
>>>>>>> able to dynamically change common properties in a single config place
>>>>>>> during runtime, as the fill made by maven would be only done once at build
>>>>>>> time right? But at runtime I would need to that as David mention, still n
>>>>>>> times right?
>>>>>>>
>>>>>>> as a use case for instance, with blueprint:cm update-strategy
>>>>>>> configured as 'reload' in combination with felix-fileinstall as directory
>>>>>>> watcher, bundles are reloaded automatically so that when I modify at
>>>>>>> anytime during runtime a property e.g with just a text editor the bundle is
>>>>>>> initiated again with the new property values which is a quite nice feature
>>>>>>>
>>>>>>> best
>>>>>>>
>>>>>>> Pablo
>>>>>>>
>>>>>>> On 12/07/2016 12:31 AM, David Jencks wrote:
>>>>>>>
>>>>>>> I’d like to make sure I understand what you are doing here…. IIUC
>>>>>>> during the build of your project you are generating multiple configuration
>>>>>>> files with the same or similar content, and each of these is loaded into a
>>>>>>> configuration which is bound to a particular bundle location? So, at build
>>>>>>> time you can change all the duplicate properties at once but if you need to
>>>>>>> change them later you have to alter n (== number of duplicate configs)
>>>>>>> independently? Whereas if you had multi-location support (and possibly
>>>>>>> multi-pid support such as DS provides) you could share a single
>>>>>>> Configuration and change the property while the framework was running in
>>>>>>> one place?
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <
>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>
>>>>>>> Pablo,
>>>>>>>
>>>>>>> One possible solution to this problem that I'm currently looking at
>>>>>>> is using a configuration bundle along with my features bundle. In the
>>>>>>> configuration bundle I have all the cfg files and use properties
>>>>>>> placeholders ${value} to set the value for key/value.
>>>>>>>
>>>>>>> In the POM I load properties files using the Maven properties plugin
>>>>>>> and that lets me set a global set of properties values that can be used in
>>>>>>> filling in the cfg values. So if a port or URI is shared across a large
>>>>>>> number of them that automatically gets filled in. The features file can
>>>>>>> then specify the cfg files to install and what name to install them with.
>>>>>>>
>>>>>>> This gets rid of a lot of tedium and by using profiles I should be
>>>>>>> able to switch dev, test and production, and have the properties
>>>>>>> automatically set correctly.
>>>>>>>
>>>>>>> I'd like to modify this a bit so that dev, test and product cfg
>>>>>>> files are all created simultaneously and simply installed in different
>>>>>>> directories inside the configuration bundle. Then by using different
>>>>>>> features installs I can easily switch between the different configurations
>>>>>>> without having to tediously edit each configuration file.
>>>>>>>
>>>>>>> Brad
>>>>>>>
>>>>>>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Does Camel/Fuse even support DS? I haven't found any documentation
>>>>>>>> saying otherwise. I've only found camel-scr which uses Felix-specific
>>>>>>>> annotations and not DS.
>>>>>>>>
>>>>>>>> On 7 July 2016 at 14:32, Brad Johnson <brad.johnson@mediadriver.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> David,
>>>>>>>>>
>>>>>>>>> That is some pretty extreme and wild speculation alright. How
>>>>>>>>> does one use blueprint to not use OSGi appropriately? In the 5 years I've
>>>>>>>>> been consulting with Fuse/Karaf/OSGi and going to various clients not one
>>>>>>>>> of them used or uses DS. Not one. They all use bundles, services, and
>>>>>>>>> Camel with blueprint. The last time I worked with DS I didn't find it
>>>>>>>>> provided any serious advantage and added another layer that I'd have to
>>>>>>>>> teach my clients. Not that I wouldn't consider it or use it if I found a
>>>>>>>>> real advantage but I haven't.
>>>>>>>>>
>>>>>>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in
>>>>>>>>> OSGi 4.x land much less 5 or 6.
>>>>>>>>>
>>>>>>>>> So for Camel are you using the Java DSL?
>>>>>>>>>
>>>>>>>>> Brad
>>>>>>>>>
>>>>>>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <
>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you look
>>>>>>>>>> at the osgi R5 or R6 config admin spec for “multi location”.
>>>>>>>>>>
>>>>>>>>>> You guys might be using blueprint every day, but there is no OSGI
>>>>>>>>>> spec work to keep it up to date or even specify obviously necessary
>>>>>>>>>> features such as config admin integration. If blueprint is so great why
>>>>>>>>>> aren’t the proponents keeping the spec related to current OSGI? This is a
>>>>>>>>>> part of my, admittedly extreme, theory that use of blueprint is related to
>>>>>>>>>> not wanting to make the app actually use osgi appropriately.
>>>>>>>>>>
>>>>>>>>>> And, the project I work on every day uses DS exclusively and
>>>>>>>>>> still finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>>>>>>>>
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> It is in here;
>>>>>>>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>>>>>>>>
>>>>>>>>>> A bundle is in aries bound to the pid. So it is actually working
>>>>>>>>>> as expected, bit of
>>>>>>>>>> a hassle since spring-dm allowed it.
>>>>>>>>>>
>>>>>>>>>> And yes selling DS into “regular" organizations is about as easy
>>>>>>>>>> as selling snow in Alaska.
>>>>>>>>>>
>>>>>>>>>> /je
>>>>>>>>>>
>>>>>>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <
>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>
>>>>>>>>>> David,
>>>>>>>>>>
>>>>>>>>>> You live in a very different world than I do. In all the
>>>>>>>>>> consulting I do with Fuse/karaf blueprint is used almost exclusively. I
>>>>>>>>>> understand DS and its uses but also its limits and overhead. It's like
>>>>>>>>>> telling me one should only use Camel Java DSL. That may be one's
>>>>>>>>>> perspective but that isn't everyone's.
>>>>>>>>>>
>>>>>>>>>> Brad
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <
>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> IMNSHO blueprint is only really plausible if you have a large
>>>>>>>>>>> amount of Spring based code and you need to convert it to be sort of
>>>>>>>>>>> osgi-compatible really quickly without understanding osgi or the code.
>>>>>>>>>>> Otherwise taking the time to understand DS and use it is much more
>>>>>>>>>>> satisfactory. DS provides this configuration override ability with support
>>>>>>>>>>> for multiple pids, although only one of the pids can turn out to be a
>>>>>>>>>>> factory configuration. There’s no obvious way of correlating factory
>>>>>>>>>>> configurations, so this restriction makes some sense.
>>>>>>>>>>>
>>>>>>>>>>> I don’t think there really are any blueprint folks. The cm
>>>>>>>>>>> stuff, while obviously required to make the spec remotely plausible, hasn’t
>>>>>>>>>>> made it into the spec in the many many years it’s been sitting around.
>>>>>>>>>>>
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <
>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> If I were to sit down with the blueprint folks today to create a
>>>>>>>>>>> wish list one thing I'd like to see is for an ability to have a
>>>>>>>>>>> configuration hierarchy specified with parent/child relationships much like
>>>>>>>>>>> one has in Maven. Have a base configuration file and be able to have
>>>>>>>>>>> another cfg file specify that one as its parent. Override properties or add
>>>>>>>>>>> them to the child. When the configuration admin fires up it would read up
>>>>>>>>>>> the chain and construct the properties.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Ray,
>>>>>>>>>>>>
>>>>>>>>>>>> If I understand your question right the answer is the Aries
>>>>>>>>>>>> extension is referencing configuration. In karaf/fuse for example the
>>>>>>>>>>>> following:
>>>>>>>>>>>>
>>>>>>>>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>
>>>>>>>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>>>>>>>
>>>>>>>>>>>> Installing that file is done either manually or by use of a
>>>>>>>>>>>> features file.
>>>>>>>>>>>>
>>>>>>>>>>>> Whenever I've attempted to use the PID in more than one bundle
>>>>>>>>>>>> it has failed and I don't think it is permitted. That's a problem I think
>>>>>>>>>>>> and something that should be fixed through some other configuration
>>>>>>>>>>>> management mechanism. Making microservices that might share common
>>>>>>>>>>>> properties, for example, becomes problematic in that regard and I've
>>>>>>>>>>>> resorted to using my own OSGi services to overcome that problem.
>>>>>>>>>>>>
>>>>>>>>>>>> Brad
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Ok, so after a brief review the cm schema is an Aries
>>>>>>>>>>>>> extension and it doesn't appear to support the location binding.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, it's unclear to me whether this extension is creating
>>>>>>>>>>>>> the configuration or merely referencing one from outside.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any Aries gurus can answer that?
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <
>>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I’m not really familiar with blueprint cm but I’d expect that
>>>>>>>>>>>>>> to indicate which pid to use to fetch the config from config admin and in
>>>>>>>>>>>>>> the ... how to map configuration propertiething blueprint substitution
>>>>>>>>>>>>>> knows about. Is that really instructions to create a new configuration and
>>>>>>>>>>>>>> populate it with data (what a management agent does)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <
>>>>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> David, I agree with everything you've said, however this
>>>>>>>>>>>>>> looks like blueprint being the agent here:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, blueprint cm shouldn’t really know about the
>>>>>>>>>>>>>>> multi-location. The management agent that is creating the configuration
>>>>>>>>>>>>>>> should be setting the bundle location to the multi-location ”?”.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I see and would it possible to configure which method is
>>>>>>>>>>>>>>> invoked from Blueprint?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is how I do it:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is there perhaps some blueprint property where I can tune
>>>>>>>>>>>>>>> the second argument in the createFactoryConfiguration?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because it looks like the fact of using config admin through
>>>>>>>>>>>>>>> blueprint binds the PID to the first bundle using it
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>> Pablo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As long as configurations are not bound to a bundle they can
>>>>>>>>>>>>>>> be used by any bundle.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The exception clearly shows that the configuration is bound
>>>>>>>>>>>>>>> to a bundle.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Creating an unbound configuration requires passing a "?" as
>>>>>>>>>>>>>>> the second arguments to getConfiguration/createFactoryConfiguration methods
>>>>>>>>>>>>>>> of CM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> HTH,
>>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Is it possible to use same config file from
>>>>>>>>>>>>>>>>> multiple bundles while using Config Admin with blueprint Blueprint?
>>>>>>>>>>>>>>>>> Because, I can't manage to do that, I get the following error:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No
>>>>>>>>>>>>>>>>> visibility to configuration bound to
>>>>>>>>>>>>>>>>> initial@reference:file:../plugin-2/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> However, I fear that this is a problem in the aries
>>>>>>>>>>>>>>>>> blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As a workaround I can make a config file per bundle that
>>>>>>>>>>>>>>>>> needs it....
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As follows the versions and bundles that I'm using related
>>>>>>>>>>>>>>>>> to the container (Running on top of Equinox 3.11):
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support
>>>>>>>>>>>>>>>>> for JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core
>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>> Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>> Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM
>>>>>>>>>>>>>>>>> (1.0.7)|1.0.7
>>>>>>>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>>> (1.5.0)|1.5.0
>>>>>>>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>>> Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed
>>>>>>>>>>>>>>>>> Contexts (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API
>>>>>>>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service
>>>>>>>>>>>>>>>>> Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>>>>>>> (1.1.1)|1.1.1
>>>>>>>>>>>>>>>>> 73|Active | 2|Aries JPA Container API
>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for
>>>>>>>>>>>>>>>>> Legacy Runtimes (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>> Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>> provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation
>>>>>>>>>>>>>>>>> API (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>>>>>>> (2.1.0)|2.1.0
>>>>>>>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation
>>>>>>>>>>>>>>>>> Impl (1.0.1)|1.0.1
>>>>>>>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>> Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>>> Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service
>>>>>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic
>>>>>>>>>>>>>>>>> Weaving Bundle (1.0.8)|1.0.8
>>>>>>>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint
>>>>>>>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 11|Active | 4|Apache Felix File Install
>>>>>>>>>>>>>>>>> (3.5.4)|3.5.4
>>>>>>>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell
>>>>>>>>>>>>>>>>> (0.12.0)|0.12.0
>>>>>>>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command
>>>>>>>>>>>>>>>>> (0.16.0)|0.16.0
>>>>>>>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime
>>>>>>>>>>>>>>>>> (0.16.2)|0.16.2
>>>>>>>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management
>>>>>>>>>>>>>>>>> Console (1.2.8)|1.2.8
>>>>>>>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin
>>>>>>>>>>>>>>>>> Service (1.8.8)|1.8.8
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email.
>>>>>>>>>>>>>>>>> The recipient should check this email and any attachments for the presence
>>>>>>>>>>>>>>>>> of viruses. The company accepts no liability for any damage caused by any
>>>>>>>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Warning: Although the company has taken reasonable
>>>>>>>>>>>>>>>>> precautions to ensure no viruses are present in this email, the company
>>>>>>>>>>>>>>>>> cannot accept responsibility for any loss or damage arising from the use of
>>>>>>>>>>>>>>>>> this email or attachments.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>>>>>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Red Hat, Open Source Integration
>>>>
>>>> Email: gnodet@redhat.com
>>>> Web: http://fusesource.com
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>>>
>>>
>>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
Re: blueprint:cm multiple bundle but same config file
Posted by David Jencks <da...@yahoo.com>.
if the declared DS services are non-exported classes in the bundle then even though it gets in the service registry it won’t be accessible outside the bundle.
You can also use a non-feature subsystem to restrict visibility to the service, but that starts getting complicated pretty rapidly.
If you are even more ambitions you can use the Region api that is used in back of the subsystem implementation or if you are foolhardy you can use framework service hooks for the same purpose.
However…. DS is not really intended to be a universal wiring framework for everything. It’s intended to provide a really good way to set up configured OSGI services. Once you start wanting private components I start wondering if the component is actually appropriate to be exposed as a service.
I would be interested in seeing something like this in xml form with an indication of what kind of wiring variability is needed or useful. I’d like to understand how much independent configuration there is, how it would be most logically grouped, and how much the wiring could just as well be written in java. I’m wondering about an approach of having basically one DS component that gets the configuration(s) and wires up the other components somehow.
thanks
david jencks
> On Aug 1, 2016, at 4:33 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Can you even make a semi-private service in DS/SCR? What could the equivalent be to a blueprint bean that isn't exported as a service? Or is the philosophy to make all services public in DS?
>
> On 1 August 2016 at 18:12, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
> Tim,
>
> After working with DS and SCR a little I can understand its benefits. One obvious advantage was being able to write basic JUnit tests to test my routes without having to fire up CBTS. I've always disliked working in XML so it is odd being in the position like I sound like I'm the one championing it.
>
> The main problem right now with Camel is that while SCR handles all the external items there isn't a way to do any injection of "local" dependencies. By that I mean within my own bundle I might have validators, handlers, local data models, etc. that I want to stand up and run in my Camel routes. Camel SCR doesn't have a mechanism for doing that.
>
> When one runs it locally in the IDE it fires up a SimpleRegistry and uses that to register everything and in that case you can manually add your own beans before setting up route definitions. If the bundle is running where it has a bundle context it instead fires up an OsgiServiceRegistry(don't recall the full name.) In that case you can't add your local beans.
>
> I noted that there is a CompositeRegistry in the AbstractCamelRunner and perhaps that should always be the one used. If one boots up and an OSGi service registry is created both it and the SimpleRegistry are added to the CompositeRegistry but one can access the SimpleRegistry in order to add one's local dependencies for Camel routes.
>
> On Wed, Jul 13, 2016 at 3:34 AM, Timothy Ward <timothyjward@apache.org <ma...@apache.org>> wrote:
> Hi Brad,
>
> I’ve been watching this thread for a while, and you’ve finally managed to draw me in :)
>
>
>> On 12 Jul 2016, at 17:42, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>
>> Guillaume,
>>
>> I'm still using Blueprint and have found Camel/SCR to be a pain to work with. It provides no tangible benefit if one is using Blueprint for routes and dependency injection anyway as it simply introduces one more way of configuring things. It was interesting to read the other day that Christian seems to have the same impression of the complexity of SCR. I remember when I first tried I thought it looked pretty cool but started running into problems.
>
> So what you’re comparing here isn’t really apples with apples. A long way back Camel provided a bunch of Spring XML sugar to make configuring Camel simpler. This was obviously a good thing because setting up Camel was (and is) hard. To this day people still use the Spring syntax for building their Camel routes. OSGi blueprint was effectively a move by Spring to standardise the Spring DM container, and so unsurprisingly blueprint looks a lot like Spring. Some people did the work to port the Camel Spring configuration to OSGi blueprint, and that’s why Camel is easy to use in blueprint.
>
> If someone actually spent some time putting together a nice integration with SCR then I’m sure that using SCR would be at least as easy as blueprint. The problem here is that relatively few SCR developers/users use Camel, and the ones that do are just told to “use blueprint”.
>
>> That DS is in its second generation and only now getting around to transactions is telling. Either it has reached its natural boundaries and is now over-reaching or wasn’t full thought out.
>
> DS is actually working on its fifth release, and transactions are nowhere to be seen. You may be referring to the Transaction Control specification, which is separate from DS. They can be used together very effectively, but you could equally use Transaction Control with blueprint.
>
> DS is actually one of the “good citizens” of the DI world in that it deliberately does less in order to do it well. There’s no dependency proxying, no aspects, just the code that you wrote injected with some other code that someone wrote.
>
>> To me it's a component and service bootstrapping mechanism which represents a small portion of the world I work in - transforms, routing, EIPs, etc. I've no reason to embrace it or deny it unless it either makes my job much easier or I can't live without it. So far adding Camel SCR and DS into the middleware just results in one more thing I have to deal with.
>
> This is a perfectly acceptable viewpoint. If the fundamental limitations of the blueprint model aren’t a problem for you then switching right now is almost certainly unnecessary.
>
>>
>> I think Blueprint works well these days and has come a long way in the past 3 years. The Aries team is to be commended for some great work.
>
> Aries Blueprint has had a lot of extensions and improvements over the last three years. Sadly the same cannot be said for the specifications or other implementations. Aries Blueprint is very much the last implementation standing, and there has been no effort to standardise the new features (or even to try fixing the problems with the original standard). The set of RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance is very telling.
>
> As far as Aries blueprint is concerned, the main reason that it is still alive seems to be the fact that it was included in Karaf, and that Karaf provides Camel integration alongside it. Even Karaf itself is starting to move to use DS internally, offering blueprint as something for applications to use.
>
>
>> I’ve been surprised by the near religious zeal of some of the DS advocates.
>
> Most OSGi developers I know (myself included) who really start to use DS consider it to be roughly equivalent to magic. The fact that the model can be as simple as it is and yet still flexible, correct and safe is both surprising and pleasing. Moving back to “not DS” is usually pretty painful and reminds people why they love DS so much.
>
>> I'll be interested in seeing the DS semantics and proxies for CDI. Heh. Proxies are another technology that I don't care about one way or the other as long as things work well and don't require a lot of configuration. So it’s great if we can get rid of proxies but not so great if I now have to trade that off for configuration of start up order on services to make sure everything is running before Camel routes come up.
>
> Actually, this is one of the places where DS really shines. If you write a DS component properly (i.e. without trying to dig out of the DS lifecycle) then startup ordering ceases to be an issue.
>
> Again, someone with a little time and expertise would probably find that Camel + DS can be a really effective solution. The problem is finding the person who has the time, expertise and inclination…
>
> Tim Ward
>
> Apache Aries PMC Member,
> OSGi IoT Expert Group Chair,
> Author Enterprise OSGi in Action
> timothyjward@apache.org <ma...@apache.org>
>>
>>
>>
>>
>>
>>
>> On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gnodet@apache.org <ma...@apache.org>> wrote:
>> I can happily review a patch if you're fancy writing one...
>>
>> And I disagree with the 'blueprint is dead and nobody cares about it anymore'. What's dead is the blueprint osgi specification for blueprint, not the Aries Blueprint project. I've recently added a bunch of important features related to spring in blueprint.
>>
>> DS also has some drawbacks as it's not extensible at all : this is leading the OSGi Alliance to write a new spec for transaction support !!!
>>
>> I think the CDI+DS extension I've been working on those past weeks could bring the best of both world : strong DS semantics for the OSGi bits, but extensibility and support for proxies provided by CDI ;-)
>>
>>
>> 2016-07-12 17:24 GMT+02:00 Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>>:
>> David,
>>
>> I'm all for multilocation support in blueprint. Can't wait for it. But it sounds like your saying blueprint is dead and nobody cares about it anymore so it doesn't seem likely to happen anytime soon. It certainly wouldn't be relevant to Fuse which uses R4 in any case.
>>
>> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>> The features file can have statements like this:
>>
>>
>> <configfile finalname="/etc/com.foo.cfg" override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
>> <configfile finalname="/etc/com.bar.cfg" override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
>> ....etc....
>> That's off the top of my head so take it with a grain of salt for syntax.
>>
>>
>> When you run the features install it will overwrite the files in the etc directory with the ones in the maven bundle which have now been updated. So instead of modifying configuration files in the etc
>> directory you modifying them in your Maven configuration project and recompile the bundle and then pull it from the repo
>> in order to update the values.
>>
>>
>> But you can still modify them in the etc if you wanted. You just have to make sure you have the cm properties set to reload.
>>
>>
>> <cm:property-placeholder persistent-id="com.foo" update-strategy="reload">
>>
>> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>> Brad, if I understand your approach too that would lead to not being able to dynamically change common properties in a single config place during runtime, as the fill made by maven would be only done once at build time right? But at runtime I would need to that as David mention, still n times right?
>> as a use case for instance, with blueprint:cm update-strategy configured as 'reload' in combination with felix-fileinstall as directory watcher, bundles are reloaded automatically so that when I modify at anytime during runtime a property e.g with just a text editor the bundle is initiated again with the new property values which is a quite nice feature
>> best
>>
>> Pablo
>>
>> On 12/07/2016 12:31 AM, David Jencks wrote:
>>> I’d like to make sure I understand what you are doing here…. IIUC during the build of your project you are generating multiple configuration files with the same or similar content, and each of these is loaded into a configuration which is bound to a particular bundle location? So, at build time you can change all the duplicate properties at once but if you need to change them later you have to alter n (== number of duplicate configs) independently? Whereas if you had multi-location support (and possibly multi-pid support such as DS provides) you could share a single Configuration and change the property while the framework was running in one place?
>>>
>>> thanks
>>> david jencks
>>>
>>>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>>
>>>> Pablo,
>>>>
>>>> One possible solution to this problem that I'm currently looking at is using a configuration bundle along with my features bundle. In the configuration bundle I have all the cfg files and use properties placeholders ${value} to set the value for key/value.
>>>>
>>>> In the POM I load properties files using the Maven properties plugin and that lets me set a global set of properties values that can be used in filling in the cfg values. So if a port or URI is shared across a large number of them that automatically gets filled in. The features file can then specify the cfg files to install and what name to install them with.
>>>>
>>>> This gets rid of a lot of tedium and by using profiles I should be able to switch dev, test and production, and have the properties automatically set correctly.
>>>>
>>>> I'd like to modify this a bit so that dev, test and product cfg files are all created simultaneously and simply installed in different directories inside the configuration bundle. Then by using different features installs I can easily switch between the different configurations without having to tediously edit each configuration file.
>>>>
>>>> Brad
>>>>
>>>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>> Does Camel/Fuse even support DS? I haven't found any documentation saying otherwise. I've only found camel-scr which uses Felix-specific annotations and not DS.
>>>>
>>>> On 7 July 2016 at 14:32, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>> David,
>>>>
>>>> That is some pretty extreme and wild speculation alright. How does one use blueprint to not use OSGi appropriately? In the 5 years I've been consulting with Fuse/Karaf/OSGi and going to various clients not one of them used or uses DS. Not one. They all use bundles, services, and Camel with blueprint. The last time I worked with DS I didn't find it provided any serious advantage and added another layer that I'd have to teach my clients. Not that I wouldn't consider it or use it if I found a real advantage but I haven't.
>>>>
>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi 4.x land much less 5 or 6.
>>>>
>>>> So for Camel are you using the Java DSL?
>>>>
>>>> Brad
>>>>
>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you look at the osgi R5 or R6 config admin spec for “multi location”.
>>>>
>>>> You guys might be using blueprint every day, but there is no OSGI spec work to keep it up to date or even specify obviously necessary features such as config admin integration. If blueprint is so great why aren’t the proponents keeping the spec related to current OSGI? This is a part of my, admittedly extreme, theory that use of blueprint is related to not wanting to make the app actually use osgi appropriately.
>>>>
>>>> And, the project I work on every day uses DS exclusively and still finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>>
>>>> david jencks
>>>>
>>>>
>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <seijoed@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> It is in here; https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html <https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html>
>>>>>
>>>>> A bundle is in aries bound to the pid. So it is actually working as expected, bit of
>>>>> a hassle since spring-dm allowed it.
>>>>>
>>>>> And yes selling DS into “regular" organizations is about as easy as selling snow in Alaska.
>>>>>
>>>>> /je
>>>>>
>>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>>>>
>>>>>> David,
>>>>>>
>>>>>> You live in a very different world than I do. In all the consulting I do with Fuse/karaf blueprint is used almost exclusively. I understand DS and its uses but also its limits and overhead. It's like telling me one should only use Camel Java DSL. That may be one's perspective but that isn't everyone's.
>>>>>>
>>>>>> Brad
>>>>>>
>>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>>>>>> IMNSHO blueprint is only really plausible if you have a large amount of Spring based code and you need to convert it to be sort of osgi-compatible really quickly without understanding osgi or the code. Otherwise taking the time to understand DS and use it is much more satisfactory. DS provides this configuration override ability with support for multiple pids, although only one of the pids can turn out to be a factory configuration. There’s no obvious way of correlating factory configurations, so this restriction makes some sense.
>>>>>>
>>>>>> I don’t think there really are any blueprint folks. The cm stuff, while obviously required to make the spec remotely plausible, hasn’t made it into the spec in the many many years it’s been sitting around.
>>>>>>
>>>>>> david jencks
>>>>>>
>>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>>>>>
>>>>>>> If I were to sit down with the blueprint folks today to create a wish list one thing I'd like to see is for an ability to have a configuration hierarchy specified with parent/child relationships much like one has in Maven. Have a base configuration file and be able to have another cfg file specify that one as its parent. Override properties or add them to the child. When the configuration admin fires up it would read up the chain and construct the properties.
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>>>>> Ray,
>>>>>>>
>>>>>>> If I understand your question right the answer is the Aries extension is referencing configuration. In karaf/fuse for example the following:
>>>>>>>
>>>>>>> <cm:property-placeholder persistent-id="com.my.foo" update-strategy="reload">
>>>>>>>
>>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>>
>>>>>>> Installing that file is done either manually or by use of a features file.
>>>>>>>
>>>>>>> Whenever I've attempted to use the PID in more than one bundle it has failed and I don't think it is permitted. That's a problem I think and something that should be fixed through some other configuration management mechanism. Making microservices that might share common properties, for example, becomes problematic in that regard and I've resorted to using my own OSGi services to overcome that problem.
>>>>>>>
>>>>>>> Brad
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
>>>>>>> Ok, so after a brief review the cm schema is an Aries extension and it doesn't appear to support the location binding.
>>>>>>>
>>>>>>> However, it's unclear to me whether this extension is creating the configuration or merely referencing one from outside.
>>>>>>>
>>>>>>> Any Aries gurus can answer that?
>>>>>>>
>>>>>>> - Ray
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>>>>>>> I’m not really familiar with blueprint cm but I’d expect that to indicate which pid to use to fetch the config from config admin and in the ... how to map configuration propertiething blueprint substitution knows about. Is that really instructions to create a new configuration and populate it with data (what a management agent does)?
>>>>>>>
>>>>>>> david jencks
>>>>>>>
>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
>>>>>>>>
>>>>>>>> David, I agree with everything you've said, however this looks like blueprint being the agent here:
>>>>>>>>
>>>>>>>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>>>>>>>> ...
>>>>>>>> </cm:property-placeholder>
>>>>>>>>
>>>>>>>> - Ray
>>>>>>>>
>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>>>>>>>> No, blueprint cm shouldn’t really know about the multi-location. The management agent that is creating the configuration should be setting the bundle location to the multi-location ”?”.
>>>>>>>>
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>>>>>>>>
>>>>>>>>> I see and would it possible to configure which method is invoked from Blueprint?
>>>>>>>>>
>>>>>>>>> This is how I do it:
>>>>>>>>>
>>>>>>>>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>>>>>>>>> ...
>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>
>>>>>>>>> is there perhaps some blueprint property where I can tune the second argument in the createFactoryConfiguration?
>>>>>>>>>
>>>>>>>>> Because it looks like the fact of using config admin through blueprint binds the PID to the first bundle using it
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> best
>>>>>>>>> Pablo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>> As long as configurations are not bound to a bundle they can be used by any bundle.
>>>>>>>>>>
>>>>>>>>>> The exception clearly shows that the configuration is bound to a bundle.
>>>>>>>>>>
>>>>>>>>>> Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> HTH,
>>>>>>>>>> - Ray
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>>>>>>>>> Hello All,
>>>>>>>>>>
>>>>>>>>>> Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
>>>>>>>>>>
>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm <http://org.osgi.service.cm/>.ManagedService, id=214,bundle=86/initial@reference:file:../plugin-1/ <mailto:bundle=86/initial@reference:file:../plugin-1/>]: No visibility to configuration bound to initial@reference:file:../plugin-2/ <mailto:initial@reference:file:../plugin-2/>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959 <https://issues.jboss.org/browse/ENTESB-3959>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As a workaround I can make a config file per bundle that needs it....
>>>>>>>>>>
>>>>>>>>>> As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
>>>>>>>>>>
>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>>>>>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
>>>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>
>>>>>>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>>>>>>>> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
>>>>>>>>>>
>>>>>>>>>> 0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>
>>>>>>>>>> Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>>>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>>
>>>
>>
>>
>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Red Hat, Open Source Integration
>>
>> Email: gnodet@redhat.com <ma...@redhat.com>
>> Web: http://fusesource.com <http://fusesource.com/>
>> Blog: http://gnodet.blogspot.com/ <http://gnodet.blogspot.com/>
>>
>>
>
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: blueprint:cm multiple bundle but same config file
Posted by Matt Sicker <bo...@gmail.com>.
Can you even make a semi-private service in DS/SCR? What could the
equivalent be to a blueprint bean that isn't exported as a service? Or is
the philosophy to make all services public in DS?
On 1 August 2016 at 18:12, Brad Johnson <br...@mediadriver.com>
wrote:
> Tim,
>
> After working with DS and SCR a little I can understand its benefits. One
> obvious advantage was being able to write basic JUnit tests to test my
> routes without having to fire up CBTS. I've always disliked working in XML
> so it is odd being in the position like I sound like I'm the one
> championing it.
>
> The main problem right now with Camel is that while SCR handles all the
> external items there isn't a way to do any injection of "local"
> dependencies. By that I mean within my own bundle I might have validators,
> handlers, local data models, etc. that I want to stand up and run in my
> Camel routes. Camel SCR doesn't have a mechanism for doing that.
>
> When one runs it locally in the IDE it fires up a SimpleRegistry and uses
> that to register everything and in that case you can manually add your own
> beans before setting up route definitions. If the bundle is running where
> it has a bundle context it instead fires up an OsgiServiceRegistry(don't
> recall the full name.) In that case you can't add your local beans.
>
> I noted that there is a CompositeRegistry in the AbstractCamelRunner and
> perhaps that should always be the one used. If one boots up and an OSGi
> service registry is created both it and the SimpleRegistry are added to the
> CompositeRegistry but one can access the SimpleRegistry in order to add
> one's local dependencies for Camel routes.
>
> On Wed, Jul 13, 2016 at 3:34 AM, Timothy Ward <ti...@apache.org>
> wrote:
>
>> Hi Brad,
>>
>> I’ve been watching this thread for a while, and you’ve finally managed to
>> draw me in :)
>>
>>
>> On 12 Jul 2016, at 17:42, Brad Johnson <br...@mediadriver.com>
>> wrote:
>>
>> Guillaume,
>>
>> I'm still using Blueprint and have found Camel/SCR to be a pain to work
>> with. It provides no tangible benefit if one is using Blueprint for routes
>> and dependency injection anyway as it simply introduces one more way of
>> configuring things. It was interesting to read the other day that Christian
>> seems to have the same impression of the complexity of SCR. I remember
>> when I first tried I thought it looked pretty cool but started running into
>> problems.
>>
>>
>> So what you’re comparing here isn’t really apples with apples. A long way
>> back Camel provided a bunch of Spring XML sugar to make configuring Camel
>> simpler. This was obviously a good thing because setting up Camel was (and
>> is) hard. To this day people still use the Spring syntax for building their
>> Camel routes. OSGi blueprint was effectively a move by Spring to
>> standardise the Spring DM container, and so unsurprisingly blueprint looks
>> a lot like Spring. Some people did the work to port the Camel Spring
>> configuration to OSGi blueprint, and that’s why Camel is easy to use in
>> blueprint.
>>
>> If someone actually spent some time putting together a nice integration
>> with SCR then I’m sure that using SCR would be at least as easy as
>> blueprint. The problem here is that relatively few SCR developers/users use
>> Camel, and the ones that do are just told to “use blueprint”.
>>
>> That DS is in its second generation and only now getting around to
>> transactions is telling. Either it has reached its natural boundaries and
>> is now over-reaching or wasn’t full thought out.
>>
>>
>> DS is actually working on its fifth release, and transactions are nowhere
>> to be seen. You may be referring to the Transaction Control specification,
>> which is separate from DS. They can be used together very effectively, but
>> you could equally use Transaction Control with blueprint.
>>
>> DS is actually one of the “good citizens” of the DI world in that it
>> deliberately does less in order to do it well. There’s no dependency
>> proxying, no aspects, just the code that you wrote injected with some other
>> code that someone wrote.
>>
>> To me it's a component and service bootstrapping mechanism which
>> represents a small portion of the world I work in - transforms, routing,
>> EIPs, etc. I've no reason to embrace it or deny it unless it either makes
>> my job much easier or I can't live without it. So far adding Camel SCR and
>> DS into the middleware just results in one more thing I have to deal with.
>>
>>
>> This is a perfectly acceptable viewpoint. If the fundamental limitations
>> of the blueprint model aren’t a problem for you then switching right now is
>> almost certainly unnecessary.
>>
>>
>> I think Blueprint works well these days and has come a long way in the
>> past 3 years. The Aries team is to be commended for some great work.
>>
>>
>> Aries Blueprint has had a lot of extensions and improvements over the
>> last three years. Sadly the same cannot be said for the specifications or
>> other implementations. Aries Blueprint is very much the last implementation
>> standing, and there has been no effort to standardise the new features (or
>> even to try fixing the problems with the original standard). The set of
>> RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance is
>> very telling.
>>
>> As far as Aries blueprint is concerned, the main reason that it is still
>> alive seems to be the fact that it was included in Karaf, and that Karaf
>> provides Camel integration alongside it. Even Karaf itself is starting to
>> move to use DS internally, offering blueprint as something for applications
>> to use.
>>
>>
>> I’ve been surprised by the near religious zeal of some of the DS
>> advocates.
>>
>>
>> Most OSGi developers I know (myself included) who really start to use DS
>> consider it to be roughly equivalent to magic. The fact that the model can
>> be as simple as it is and yet still flexible, correct and safe is both
>> surprising and pleasing. Moving back to “not DS” is usually pretty painful
>> and reminds people why they love DS so much.
>>
>> I'll be interested in seeing the DS semantics and proxies for CDI. Heh.
>> Proxies are another technology that I don't care about one way or the other
>> as long as things work well and don't require a lot of configuration. So
>> it’s great if we can get rid of proxies but not so great if I now have to
>> trade that off for configuration of start up order on services to make sure
>> everything is running before Camel routes come up.
>>
>>
>> Actually, this is one of the places where DS really shines. If you write
>> a DS component properly (i.e. without trying to dig out of the DS
>> lifecycle) then startup ordering ceases to be an issue.
>>
>> Again, someone with a little time and expertise would probably find that
>> Camel + DS can be a really effective solution. The problem is finding the
>> person who has the time, expertise and inclination…
>>
>> Tim Ward
>>
>> Apache Aries PMC Member,
>> OSGi IoT Expert Group Chair,
>> Author Enterprise OSGi in Action
>> timothyjward@apache.org
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gn...@apache.org>
>> wrote:
>>
>>> I can happily review a patch if you're fancy writing one...
>>>
>>> And I disagree with the 'blueprint is dead and nobody cares about it
>>> anymore'. What's dead is the blueprint osgi specification for blueprint,
>>> not the Aries Blueprint project. I've recently added a bunch of important
>>> features related to spring in blueprint.
>>>
>>> DS also has some drawbacks as it's not extensible at all : this is
>>> leading the OSGi Alliance to write a new spec for transaction support !!!
>>>
>>> I think the CDI+DS extension I've been working on those past weeks could
>>> bring the best of both world : strong DS semantics for the OSGi bits, but
>>> extensibility and support for proxies provided by CDI ;-)
>>>
>>>
>>> 2016-07-12 17:24 GMT+02:00 Brad Johnson <br...@mediadriver.com>:
>>>
>>>> David,
>>>>
>>>> I'm all for multilocation support in blueprint. Can't wait for it.
>>>> But it sounds like your saying blueprint is dead and nobody cares about it
>>>> anymore so it doesn't seem likely to happen anytime soon. It certainly
>>>> wouldn't be relevant to Fuse which uses R4 in any case.
>>>>
>>>> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <
>>>> brad.johnson@mediadriver.com> wrote:
>>>>
>>>>> The features file can have statements like this:
>>>>>
>>>>>
>>>>> <configfile finalname="/etc/com.foo.cfg"
>>>>> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
>>>>> <configfile finalname="/etc/com.bar.cfg"
>>>>> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
>>>>> ....etc....
>>>>> That's off the top of my head so take it with a grain of salt for
>>>>> syntax.
>>>>>
>>>>> When you run the features install it will overwrite the files in the
>>>>> etc directory with the ones in the maven bundle which have now been
>>>>> updated. So instead of modifying configuration files in the etc directory
>>>>> you modifying them in your Maven configuration project and recompile the
>>>>> bundle and then pull it from the repo
>>>>> in order to update the values.
>>>>>
>>>>> But you can still modify them in the etc if you wanted. You just have
>>>>> to make sure you have the cm properties set to reload.
>>>>>
>>>>> <cm:property-placeholder persistent-id="com.foo"
>>>>> update-strategy="reload">
>>>>>
>>>>> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <
>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>
>>>>>> Brad, if I understand your approach too that would lead to not being
>>>>>> able to dynamically change common properties in a single config place
>>>>>> during runtime, as the fill made by maven would be only done once at build
>>>>>> time right? But at runtime I would need to that as David mention, still n
>>>>>> times right?
>>>>>>
>>>>>> as a use case for instance, with blueprint:cm update-strategy
>>>>>> configured as 'reload' in combination with felix-fileinstall as directory
>>>>>> watcher, bundles are reloaded automatically so that when I modify at
>>>>>> anytime during runtime a property e.g with just a text editor the bundle is
>>>>>> initiated again with the new property values which is a quite nice feature
>>>>>>
>>>>>> best
>>>>>>
>>>>>> Pablo
>>>>>>
>>>>>> On 12/07/2016 12:31 AM, David Jencks wrote:
>>>>>>
>>>>>> I’d like to make sure I understand what you are doing here…. IIUC
>>>>>> during the build of your project you are generating multiple configuration
>>>>>> files with the same or similar content, and each of these is loaded into a
>>>>>> configuration which is bound to a particular bundle location? So, at build
>>>>>> time you can change all the duplicate properties at once but if you need to
>>>>>> change them later you have to alter n (== number of duplicate configs)
>>>>>> independently? Whereas if you had multi-location support (and possibly
>>>>>> multi-pid support such as DS provides) you could share a single
>>>>>> Configuration and change the property while the framework was running in
>>>>>> one place?
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <
>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>
>>>>>> Pablo,
>>>>>>
>>>>>> One possible solution to this problem that I'm currently looking at
>>>>>> is using a configuration bundle along with my features bundle. In the
>>>>>> configuration bundle I have all the cfg files and use properties
>>>>>> placeholders ${value} to set the value for key/value.
>>>>>>
>>>>>> In the POM I load properties files using the Maven properties plugin
>>>>>> and that lets me set a global set of properties values that can be used in
>>>>>> filling in the cfg values. So if a port or URI is shared across a large
>>>>>> number of them that automatically gets filled in. The features file can
>>>>>> then specify the cfg files to install and what name to install them with.
>>>>>>
>>>>>> This gets rid of a lot of tedium and by using profiles I should be
>>>>>> able to switch dev, test and production, and have the properties
>>>>>> automatically set correctly.
>>>>>>
>>>>>> I'd like to modify this a bit so that dev, test and product cfg files
>>>>>> are all created simultaneously and simply installed in different
>>>>>> directories inside the configuration bundle. Then by using different
>>>>>> features installs I can easily switch between the different configurations
>>>>>> without having to tediously edit each configuration file.
>>>>>>
>>>>>> Brad
>>>>>>
>>>>>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Does Camel/Fuse even support DS? I haven't found any documentation
>>>>>>> saying otherwise. I've only found camel-scr which uses Felix-specific
>>>>>>> annotations and not DS.
>>>>>>>
>>>>>>> On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> David,
>>>>>>>>
>>>>>>>> That is some pretty extreme and wild speculation alright. How does
>>>>>>>> one use blueprint to not use OSGi appropriately? In the 5 years I've been
>>>>>>>> consulting with Fuse/Karaf/OSGi and going to various clients not one of
>>>>>>>> them used or uses DS. Not one. They all use bundles, services, and Camel
>>>>>>>> with blueprint. The last time I worked with DS I didn't find it provided
>>>>>>>> any serious advantage and added another layer that I'd have to teach my
>>>>>>>> clients. Not that I wouldn't consider it or use it if I found a real
>>>>>>>> advantage but I haven't.
>>>>>>>>
>>>>>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in
>>>>>>>> OSGi 4.x land much less 5 or 6.
>>>>>>>>
>>>>>>>> So for Camel are you using the Java DSL?
>>>>>>>>
>>>>>>>> Brad
>>>>>>>>
>>>>>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <
>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>
>>>>>>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you look
>>>>>>>>> at the osgi R5 or R6 config admin spec for “multi location”.
>>>>>>>>>
>>>>>>>>> You guys might be using blueprint every day, but there is no OSGI
>>>>>>>>> spec work to keep it up to date or even specify obviously necessary
>>>>>>>>> features such as config admin integration. If blueprint is so great why
>>>>>>>>> aren’t the proponents keeping the spec related to current OSGI? This is a
>>>>>>>>> part of my, admittedly extreme, theory that use of blueprint is related to
>>>>>>>>> not wanting to make the app actually use osgi appropriately.
>>>>>>>>>
>>>>>>>>> And, the project I work on every day uses DS exclusively and still
>>>>>>>>> finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>>>>>>>
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> It is in here;
>>>>>>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>>>>>>>
>>>>>>>>> A bundle is in aries bound to the pid. So it is actually working
>>>>>>>>> as expected, bit of
>>>>>>>>> a hassle since spring-dm allowed it.
>>>>>>>>>
>>>>>>>>> And yes selling DS into “regular" organizations is about as easy
>>>>>>>>> as selling snow in Alaska.
>>>>>>>>>
>>>>>>>>> /je
>>>>>>>>>
>>>>>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <
>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>
>>>>>>>>> David,
>>>>>>>>>
>>>>>>>>> You live in a very different world than I do. In all the
>>>>>>>>> consulting I do with Fuse/karaf blueprint is used almost exclusively. I
>>>>>>>>> understand DS and its uses but also its limits and overhead. It's like
>>>>>>>>> telling me one should only use Camel Java DSL. That may be one's
>>>>>>>>> perspective but that isn't everyone's.
>>>>>>>>>
>>>>>>>>> Brad
>>>>>>>>>
>>>>>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <
>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>>> IMNSHO blueprint is only really plausible if you have a large
>>>>>>>>>> amount of Spring based code and you need to convert it to be sort of
>>>>>>>>>> osgi-compatible really quickly without understanding osgi or the code.
>>>>>>>>>> Otherwise taking the time to understand DS and use it is much more
>>>>>>>>>> satisfactory. DS provides this configuration override ability with support
>>>>>>>>>> for multiple pids, although only one of the pids can turn out to be a
>>>>>>>>>> factory configuration. There’s no obvious way of correlating factory
>>>>>>>>>> configurations, so this restriction makes some sense.
>>>>>>>>>>
>>>>>>>>>> I don’t think there really are any blueprint folks. The cm
>>>>>>>>>> stuff, while obviously required to make the spec remotely plausible, hasn’t
>>>>>>>>>> made it into the spec in the many many years it’s been sitting around.
>>>>>>>>>>
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <
>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>
>>>>>>>>>> If I were to sit down with the blueprint folks today to create a
>>>>>>>>>> wish list one thing I'd like to see is for an ability to have a
>>>>>>>>>> configuration hierarchy specified with parent/child relationships much like
>>>>>>>>>> one has in Maven. Have a base configuration file and be able to have
>>>>>>>>>> another cfg file specify that one as its parent. Override properties or add
>>>>>>>>>> them to the child. When the configuration admin fires up it would read up
>>>>>>>>>> the chain and construct the properties.
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Ray,
>>>>>>>>>>>
>>>>>>>>>>> If I understand your question right the answer is the Aries
>>>>>>>>>>> extension is referencing configuration. In karaf/fuse for example the
>>>>>>>>>>> following:
>>>>>>>>>>>
>>>>>>>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>
>>>>>>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>>>>>>
>>>>>>>>>>> Installing that file is done either manually or by use of a
>>>>>>>>>>> features file.
>>>>>>>>>>>
>>>>>>>>>>> Whenever I've attempted to use the PID in more than one bundle
>>>>>>>>>>> it has failed and I don't think it is permitted. That's a problem I think
>>>>>>>>>>> and something that should be fixed through some other configuration
>>>>>>>>>>> management mechanism. Making microservices that might share common
>>>>>>>>>>> properties, for example, becomes problematic in that regard and I've
>>>>>>>>>>> resorted to using my own OSGi services to overcome that problem.
>>>>>>>>>>>
>>>>>>>>>>> Brad
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Ok, so after a brief review the cm schema is an Aries extension
>>>>>>>>>>>> and it doesn't appear to support the location binding.
>>>>>>>>>>>>
>>>>>>>>>>>> However, it's unclear to me whether this extension is creating
>>>>>>>>>>>> the configuration or merely referencing one from outside.
>>>>>>>>>>>>
>>>>>>>>>>>> Any Aries gurus can answer that?
>>>>>>>>>>>>
>>>>>>>>>>>> - Ray
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <
>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I’m not really familiar with blueprint cm but I’d expect that
>>>>>>>>>>>>> to indicate which pid to use to fetch the config from config admin and in
>>>>>>>>>>>>> the ... how to map configuration propertiething blueprint substitution
>>>>>>>>>>>>> knows about. Is that really instructions to create a new configuration and
>>>>>>>>>>>>> populate it with data (what a management agent does)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <
>>>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> David, I agree with everything you've said, however this looks
>>>>>>>>>>>>> like blueprint being the agent here:
>>>>>>>>>>>>>
>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, blueprint cm shouldn’t really know about the
>>>>>>>>>>>>>> multi-location. The management agent that is creating the configuration
>>>>>>>>>>>>>> should be setting the bundle location to the multi-location ”?”.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I see and would it possible to configure which method is
>>>>>>>>>>>>>> invoked from Blueprint?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is how I do it:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> is there perhaps some blueprint property where I can tune the
>>>>>>>>>>>>>> second argument in the createFactoryConfiguration?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because it looks like the fact of using config admin through
>>>>>>>>>>>>>> blueprint binds the PID to the first bundle using it
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> best
>>>>>>>>>>>>>> Pablo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As long as configurations are not bound to a bundle they can
>>>>>>>>>>>>>> be used by any bundle.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The exception clearly shows that the configuration is bound
>>>>>>>>>>>>>> to a bundle.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Creating an unbound configuration requires passing a "?" as
>>>>>>>>>>>>>> the second arguments to getConfiguration/createFactoryConfiguration methods
>>>>>>>>>>>>>> of CM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> HTH,
>>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is it possible to use same config file from
>>>>>>>>>>>>>>>> multiple bundles while using Config Admin with blueprint Blueprint?
>>>>>>>>>>>>>>>> Because, I can't manage to do that, I get the following error:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No
>>>>>>>>>>>>>>>> visibility to configuration bound to
>>>>>>>>>>>>>>>> initial@reference:file:../plugin-2/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> However, I fear that this is a problem in the aries
>>>>>>>>>>>>>>>> blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As a workaround I can make a config file per bundle that
>>>>>>>>>>>>>>>> needs it....
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As follows the versions and bundles that I'm using related
>>>>>>>>>>>>>>>> to the container (Running on top of Equinox 3.11):
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for
>>>>>>>>>>>>>>>> JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology
>>>>>>>>>>>>>>>> Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>> Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM
>>>>>>>>>>>>>>>> (1.0.7)|1.0.7
>>>>>>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>> (1.5.0)|1.5.0
>>>>>>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core
>>>>>>>>>>>>>>>> Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed
>>>>>>>>>>>>>>>> Contexts (1.0.4)|1.0.4
>>>>>>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service
>>>>>>>>>>>>>>>> Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>>>>>> (1.1.1)|1.1.1
>>>>>>>>>>>>>>>> 73|Active | 2|Aries JPA Container API
>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for
>>>>>>>>>>>>>>>> Legacy Runtimes (1.0.0)|1.0.0
>>>>>>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>> Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin provider
>>>>>>>>>>>>>>>> TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation
>>>>>>>>>>>>>>>> API (1.0.1)|1.0.1
>>>>>>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>>>>>> (2.1.0)|2.1.0
>>>>>>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation
>>>>>>>>>>>>>>>> Impl (1.0.1)|1.0.1
>>>>>>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>> Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin
>>>>>>>>>>>>>>>> Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service
>>>>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic
>>>>>>>>>>>>>>>> Weaving Bundle (1.0.8)|1.0.8
>>>>>>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint
>>>>>>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 11|Active | 4|Apache Felix File Install
>>>>>>>>>>>>>>>> (3.5.4)|3.5.4
>>>>>>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell
>>>>>>>>>>>>>>>> (0.12.0)|0.12.0
>>>>>>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command
>>>>>>>>>>>>>>>> (0.16.0)|0.16.0
>>>>>>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime
>>>>>>>>>>>>>>>> (0.16.2)|0.16.2
>>>>>>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>>>>>>>>>>>>> (1.2.8)|1.2.8
>>>>>>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin
>>>>>>>>>>>>>>>> Service (1.8.8)|1.8.8
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email. The
>>>>>>>>>>>>>>>> recipient should check this email and any attachments for the presence of
>>>>>>>>>>>>>>>> viruses. The company accepts no liability for any damage caused by any
>>>>>>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Warning: Although the company has taken reasonable
>>>>>>>>>>>>>>>> precautions to ensure no viruses are present in this email, the company
>>>>>>>>>>>>>>>> cannot accept responsibility for any loss or damage arising from the use of
>>>>>>>>>>>>>>>> this email or attachments.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Red Hat, Open Source Integration
>>>
>>> Email: gnodet@redhat.com
>>> Web: http://fusesource.com
>>> Blog: http://gnodet.blogspot.com/
>>>
>>>
>>
>>
>
--
Matt Sicker <bo...@gmail.com>
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
Tim,
After working with DS and SCR a little I can understand its benefits. One
obvious advantage was being able to write basic JUnit tests to test my
routes without having to fire up CBTS. I've always disliked working in XML
so it is odd being in the position like I sound like I'm the one
championing it.
The main problem right now with Camel is that while SCR handles all the
external items there isn't a way to do any injection of "local"
dependencies. By that I mean within my own bundle I might have validators,
handlers, local data models, etc. that I want to stand up and run in my
Camel routes. Camel SCR doesn't have a mechanism for doing that.
When one runs it locally in the IDE it fires up a SimpleRegistry and uses
that to register everything and in that case you can manually add your own
beans before setting up route definitions. If the bundle is running where
it has a bundle context it instead fires up an OsgiServiceRegistry(don't
recall the full name.) In that case you can't add your local beans.
I noted that there is a CompositeRegistry in the AbstractCamelRunner and
perhaps that should always be the one used. If one boots up and an OSGi
service registry is created both it and the SimpleRegistry are added to the
CompositeRegistry but one can access the SimpleRegistry in order to add
one's local dependencies for Camel routes.
On Wed, Jul 13, 2016 at 3:34 AM, Timothy Ward <ti...@apache.org>
wrote:
> Hi Brad,
>
> I’ve been watching this thread for a while, and you’ve finally managed to
> draw me in :)
>
>
> On 12 Jul 2016, at 17:42, Brad Johnson <br...@mediadriver.com>
> wrote:
>
> Guillaume,
>
> I'm still using Blueprint and have found Camel/SCR to be a pain to work
> with. It provides no tangible benefit if one is using Blueprint for routes
> and dependency injection anyway as it simply introduces one more way of
> configuring things. It was interesting to read the other day that Christian
> seems to have the same impression of the complexity of SCR. I remember
> when I first tried I thought it looked pretty cool but started running into
> problems.
>
>
> So what you’re comparing here isn’t really apples with apples. A long way
> back Camel provided a bunch of Spring XML sugar to make configuring Camel
> simpler. This was obviously a good thing because setting up Camel was (and
> is) hard. To this day people still use the Spring syntax for building their
> Camel routes. OSGi blueprint was effectively a move by Spring to
> standardise the Spring DM container, and so unsurprisingly blueprint looks
> a lot like Spring. Some people did the work to port the Camel Spring
> configuration to OSGi blueprint, and that’s why Camel is easy to use in
> blueprint.
>
> If someone actually spent some time putting together a nice integration
> with SCR then I’m sure that using SCR would be at least as easy as
> blueprint. The problem here is that relatively few SCR developers/users use
> Camel, and the ones that do are just told to “use blueprint”.
>
> That DS is in its second generation and only now getting around to
> transactions is telling. Either it has reached its natural boundaries and
> is now over-reaching or wasn’t full thought out.
>
>
> DS is actually working on its fifth release, and transactions are nowhere
> to be seen. You may be referring to the Transaction Control specification,
> which is separate from DS. They can be used together very effectively, but
> you could equally use Transaction Control with blueprint.
>
> DS is actually one of the “good citizens” of the DI world in that it
> deliberately does less in order to do it well. There’s no dependency
> proxying, no aspects, just the code that you wrote injected with some other
> code that someone wrote.
>
> To me it's a component and service bootstrapping mechanism which
> represents a small portion of the world I work in - transforms, routing,
> EIPs, etc. I've no reason to embrace it or deny it unless it either makes
> my job much easier or I can't live without it. So far adding Camel SCR and
> DS into the middleware just results in one more thing I have to deal with.
>
>
> This is a perfectly acceptable viewpoint. If the fundamental limitations
> of the blueprint model aren’t a problem for you then switching right now is
> almost certainly unnecessary.
>
>
> I think Blueprint works well these days and has come a long way in the
> past 3 years. The Aries team is to be commended for some great work.
>
>
> Aries Blueprint has had a lot of extensions and improvements over the last
> three years. Sadly the same cannot be said for the specifications or other
> implementations. Aries Blueprint is very much the last implementation
> standing, and there has been no effort to standardise the new features (or
> even to try fixing the problems with the original standard). The set of
> RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance is
> very telling.
>
> As far as Aries blueprint is concerned, the main reason that it is still
> alive seems to be the fact that it was included in Karaf, and that Karaf
> provides Camel integration alongside it. Even Karaf itself is starting to
> move to use DS internally, offering blueprint as something for applications
> to use.
>
>
> I’ve been surprised by the near religious zeal of some of the DS
> advocates.
>
>
> Most OSGi developers I know (myself included) who really start to use DS
> consider it to be roughly equivalent to magic. The fact that the model can
> be as simple as it is and yet still flexible, correct and safe is both
> surprising and pleasing. Moving back to “not DS” is usually pretty painful
> and reminds people why they love DS so much.
>
> I'll be interested in seeing the DS semantics and proxies for CDI. Heh.
> Proxies are another technology that I don't care about one way or the other
> as long as things work well and don't require a lot of configuration. So
> it’s great if we can get rid of proxies but not so great if I now have to
> trade that off for configuration of start up order on services to make sure
> everything is running before Camel routes come up.
>
>
> Actually, this is one of the places where DS really shines. If you write a
> DS component properly (i.e. without trying to dig out of the DS lifecycle)
> then startup ordering ceases to be an issue.
>
> Again, someone with a little time and expertise would probably find that
> Camel + DS can be a really effective solution. The problem is finding the
> person who has the time, expertise and inclination…
>
> Tim Ward
>
> Apache Aries PMC Member,
> OSGi IoT Expert Group Chair,
> Author Enterprise OSGi in Action
> timothyjward@apache.org
>
>
>
>
>
>
>
> On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gn...@apache.org>
> wrote:
>
>> I can happily review a patch if you're fancy writing one...
>>
>> And I disagree with the 'blueprint is dead and nobody cares about it
>> anymore'. What's dead is the blueprint osgi specification for blueprint,
>> not the Aries Blueprint project. I've recently added a bunch of important
>> features related to spring in blueprint.
>>
>> DS also has some drawbacks as it's not extensible at all : this is
>> leading the OSGi Alliance to write a new spec for transaction support !!!
>>
>> I think the CDI+DS extension I've been working on those past weeks could
>> bring the best of both world : strong DS semantics for the OSGi bits, but
>> extensibility and support for proxies provided by CDI ;-)
>>
>>
>> 2016-07-12 17:24 GMT+02:00 Brad Johnson <br...@mediadriver.com>:
>>
>>> David,
>>>
>>> I'm all for multilocation support in blueprint. Can't wait for it.
>>> But it sounds like your saying blueprint is dead and nobody cares about it
>>> anymore so it doesn't seem likely to happen anytime soon. It certainly
>>> wouldn't be relevant to Fuse which uses R4 in any case.
>>>
>>> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <
>>> brad.johnson@mediadriver.com> wrote:
>>>
>>>> The features file can have statements like this:
>>>>
>>>>
>>>> <configfile finalname="/etc/com.foo.cfg"
>>>> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
>>>> <configfile finalname="/etc/com.bar.cfg"
>>>> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
>>>> ....etc....
>>>> That's off the top of my head so take it with a grain of salt for
>>>> syntax.
>>>>
>>>> When you run the features install it will overwrite the files in the
>>>> etc directory with the ones in the maven bundle which have now been
>>>> updated. So instead of modifying configuration files in the etc directory
>>>> you modifying them in your Maven configuration project and recompile the
>>>> bundle and then pull it from the repo
>>>> in order to update the values.
>>>>
>>>> But you can still modify them in the etc if you wanted. You just have
>>>> to make sure you have the cm properties set to reload.
>>>>
>>>> <cm:property-placeholder persistent-id="com.foo"
>>>> update-strategy="reload">
>>>>
>>>> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <
>>>> pablo.gomez@faw.jku.at> wrote:
>>>>
>>>>> Brad, if I understand your approach too that would lead to not being
>>>>> able to dynamically change common properties in a single config place
>>>>> during runtime, as the fill made by maven would be only done once at build
>>>>> time right? But at runtime I would need to that as David mention, still n
>>>>> times right?
>>>>>
>>>>> as a use case for instance, with blueprint:cm update-strategy
>>>>> configured as 'reload' in combination with felix-fileinstall as directory
>>>>> watcher, bundles are reloaded automatically so that when I modify at
>>>>> anytime during runtime a property e.g with just a text editor the bundle is
>>>>> initiated again with the new property values which is a quite nice feature
>>>>>
>>>>> best
>>>>>
>>>>> Pablo
>>>>>
>>>>> On 12/07/2016 12:31 AM, David Jencks wrote:
>>>>>
>>>>> I’d like to make sure I understand what you are doing here…. IIUC
>>>>> during the build of your project you are generating multiple configuration
>>>>> files with the same or similar content, and each of these is loaded into a
>>>>> configuration which is bound to a particular bundle location? So, at build
>>>>> time you can change all the duplicate properties at once but if you need to
>>>>> change them later you have to alter n (== number of duplicate configs)
>>>>> independently? Whereas if you had multi-location support (and possibly
>>>>> multi-pid support such as DS provides) you could share a single
>>>>> Configuration and change the property while the framework was running in
>>>>> one place?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <
>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>
>>>>> Pablo,
>>>>>
>>>>> One possible solution to this problem that I'm currently looking at is
>>>>> using a configuration bundle along with my features bundle. In the
>>>>> configuration bundle I have all the cfg files and use properties
>>>>> placeholders ${value} to set the value for key/value.
>>>>>
>>>>> In the POM I load properties files using the Maven properties plugin
>>>>> and that lets me set a global set of properties values that can be used in
>>>>> filling in the cfg values. So if a port or URI is shared across a large
>>>>> number of them that automatically gets filled in. The features file can
>>>>> then specify the cfg files to install and what name to install them with.
>>>>>
>>>>> This gets rid of a lot of tedium and by using profiles I should be
>>>>> able to switch dev, test and production, and have the properties
>>>>> automatically set correctly.
>>>>>
>>>>> I'd like to modify this a bit so that dev, test and product cfg files
>>>>> are all created simultaneously and simply installed in different
>>>>> directories inside the configuration bundle. Then by using different
>>>>> features installs I can easily switch between the different configurations
>>>>> without having to tediously edit each configuration file.
>>>>>
>>>>> Brad
>>>>>
>>>>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>>> Does Camel/Fuse even support DS? I haven't found any documentation
>>>>>> saying otherwise. I've only found camel-scr which uses Felix-specific
>>>>>> annotations and not DS.
>>>>>>
>>>>>> On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com>
>>>>>> wrote:
>>>>>>
>>>>>>> David,
>>>>>>>
>>>>>>> That is some pretty extreme and wild speculation alright. How does
>>>>>>> one use blueprint to not use OSGi appropriately? In the 5 years I've been
>>>>>>> consulting with Fuse/Karaf/OSGi and going to various clients not one of
>>>>>>> them used or uses DS. Not one. They all use bundles, services, and Camel
>>>>>>> with blueprint. The last time I worked with DS I didn't find it provided
>>>>>>> any serious advantage and added another layer that I'd have to teach my
>>>>>>> clients. Not that I wouldn't consider it or use it if I found a real
>>>>>>> advantage but I haven't.
>>>>>>>
>>>>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi
>>>>>>> 4.x land much less 5 or 6.
>>>>>>>
>>>>>>> So for Camel are you using the Java DSL?
>>>>>>>
>>>>>>> Brad
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <david_jencks@yahoo.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you look at
>>>>>>>> the osgi R5 or R6 config admin spec for “multi location”.
>>>>>>>>
>>>>>>>> You guys might be using blueprint every day, but there is no OSGI
>>>>>>>> spec work to keep it up to date or even specify obviously necessary
>>>>>>>> features such as config admin integration. If blueprint is so great why
>>>>>>>> aren’t the proponents keeping the spec related to current OSGI? This is a
>>>>>>>> part of my, admittedly extreme, theory that use of blueprint is related to
>>>>>>>> not wanting to make the app actually use osgi appropriately.
>>>>>>>>
>>>>>>>> And, the project I work on every day uses DS exclusively and still
>>>>>>>> finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>>>>>>
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> It is in here;
>>>>>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>>>>>>
>>>>>>>> A bundle is in aries bound to the pid. So it is actually working as
>>>>>>>> expected, bit of
>>>>>>>> a hassle since spring-dm allowed it.
>>>>>>>>
>>>>>>>> And yes selling DS into “regular" organizations is about as easy as
>>>>>>>> selling snow in Alaska.
>>>>>>>>
>>>>>>>> /je
>>>>>>>>
>>>>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <
>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>
>>>>>>>> David,
>>>>>>>>
>>>>>>>> You live in a very different world than I do. In all the
>>>>>>>> consulting I do with Fuse/karaf blueprint is used almost exclusively. I
>>>>>>>> understand DS and its uses but also its limits and overhead. It's like
>>>>>>>> telling me one should only use Camel Java DSL. That may be one's
>>>>>>>> perspective but that isn't everyone's.
>>>>>>>>
>>>>>>>> Brad
>>>>>>>>
>>>>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <
>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>
>>>>>>>>> IMNSHO blueprint is only really plausible if you have a large
>>>>>>>>> amount of Spring based code and you need to convert it to be sort of
>>>>>>>>> osgi-compatible really quickly without understanding osgi or the code.
>>>>>>>>> Otherwise taking the time to understand DS and use it is much more
>>>>>>>>> satisfactory. DS provides this configuration override ability with support
>>>>>>>>> for multiple pids, although only one of the pids can turn out to be a
>>>>>>>>> factory configuration. There’s no obvious way of correlating factory
>>>>>>>>> configurations, so this restriction makes some sense.
>>>>>>>>>
>>>>>>>>> I don’t think there really are any blueprint folks. The cm stuff,
>>>>>>>>> while obviously required to make the spec remotely plausible, hasn’t made
>>>>>>>>> it into the spec in the many many years it’s been sitting around.
>>>>>>>>>
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <
>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>
>>>>>>>>> If I were to sit down with the blueprint folks today to create a
>>>>>>>>> wish list one thing I'd like to see is for an ability to have a
>>>>>>>>> configuration hierarchy specified with parent/child relationships much like
>>>>>>>>> one has in Maven. Have a base configuration file and be able to have
>>>>>>>>> another cfg file specify that one as its parent. Override properties or add
>>>>>>>>> them to the child. When the configuration admin fires up it would read up
>>>>>>>>> the chain and construct the properties.
>>>>>>>>>
>>>>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>
>>>>>>>>>> Ray,
>>>>>>>>>>
>>>>>>>>>> If I understand your question right the answer is the Aries
>>>>>>>>>> extension is referencing configuration. In karaf/fuse for example the
>>>>>>>>>> following:
>>>>>>>>>>
>>>>>>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>
>>>>>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>>>>>
>>>>>>>>>> Installing that file is done either manually or by use of a
>>>>>>>>>> features file.
>>>>>>>>>>
>>>>>>>>>> Whenever I've attempted to use the PID in more than one bundle it
>>>>>>>>>> has failed and I don't think it is permitted. That's a problem I think and
>>>>>>>>>> something that should be fixed through some other configuration management
>>>>>>>>>> mechanism. Making microservices that might share common properties, for
>>>>>>>>>> example, becomes problematic in that regard and I've resorted to using my
>>>>>>>>>> own OSGi services to overcome that problem.
>>>>>>>>>>
>>>>>>>>>> Brad
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Ok, so after a brief review the cm schema is an Aries extension
>>>>>>>>>>> and it doesn't appear to support the location binding.
>>>>>>>>>>>
>>>>>>>>>>> However, it's unclear to me whether this extension is creating
>>>>>>>>>>> the configuration or merely referencing one from outside.
>>>>>>>>>>>
>>>>>>>>>>> Any Aries gurus can answer that?
>>>>>>>>>>>
>>>>>>>>>>> - Ray
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <
>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I’m not really familiar with blueprint cm but I’d expect that
>>>>>>>>>>>> to indicate which pid to use to fetch the config from config admin and in
>>>>>>>>>>>> the ... how to map configuration propertiething blueprint substitution
>>>>>>>>>>>> knows about. Is that really instructions to create a new configuration and
>>>>>>>>>>>> populate it with data (what a management agent does)?
>>>>>>>>>>>>
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <
>>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> David, I agree with everything you've said, however this looks
>>>>>>>>>>>> like blueprint being the agent here:
>>>>>>>>>>>>
>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>> ...
>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>
>>>>>>>>>>>> - Ray
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> No, blueprint cm shouldn’t really know about the
>>>>>>>>>>>>> multi-location. The management agent that is creating the configuration
>>>>>>>>>>>>> should be setting the bundle location to the multi-location ”?”.
>>>>>>>>>>>>>
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I see and would it possible to configure which method is
>>>>>>>>>>>>> invoked from Blueprint?
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is how I do it:
>>>>>>>>>>>>>
>>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>>
>>>>>>>>>>>>> is there perhaps some blueprint property where I can tune the
>>>>>>>>>>>>> second argument in the createFactoryConfiguration?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because it looks like the fact of using config admin through
>>>>>>>>>>>>> blueprint binds the PID to the first bundle using it
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> best
>>>>>>>>>>>>> Pablo
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> As long as configurations are not bound to a bundle they can
>>>>>>>>>>>>> be used by any bundle.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The exception clearly shows that the configuration is bound to
>>>>>>>>>>>>> a bundle.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Creating an unbound configuration requires passing a "?" as
>>>>>>>>>>>>> the second arguments to getConfiguration/createFactoryConfiguration methods
>>>>>>>>>>>>> of CM.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> HTH,
>>>>>>>>>>>>> - Ray
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is it possible to use same config file from
>>>>>>>>>>>>>>> multiple bundles while using Config Admin with blueprint Blueprint?
>>>>>>>>>>>>>>> Because, I can't manage to do that, I get the following error:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No
>>>>>>>>>>>>>>> visibility to configuration bound to
>>>>>>>>>>>>>>> initial@reference:file:../plugin-2/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, I fear that this is a problem in the aries
>>>>>>>>>>>>>>> blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As a workaround I can make a config file per bundle that
>>>>>>>>>>>>>>> needs it....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As follows the versions and bundles that I'm using related
>>>>>>>>>>>>>>> to the container (Running on top of Equinox 3.11):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for
>>>>>>>>>>>>>>> JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology
>>>>>>>>>>>>>>> Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>>>>> Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM
>>>>>>>>>>>>>>> (1.0.7)|1.0.7
>>>>>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core
>>>>>>>>>>>>>>> (1.5.0)|1.5.0
>>>>>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core
>>>>>>>>>>>>>>> Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service
>>>>>>>>>>>>>>> Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>>>>> (1.1.1)|1.1.1
>>>>>>>>>>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy
>>>>>>>>>>>>>>> Runtimes (1.0.0)|1.0.0
>>>>>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>>>>> Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin provider
>>>>>>>>>>>>>>> TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation
>>>>>>>>>>>>>>> API (1.0.1)|1.0.1
>>>>>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>>>>> (2.1.0)|2.1.0
>>>>>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation
>>>>>>>>>>>>>>> Impl (1.0.1)|1.0.1
>>>>>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>>>>> Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>>>>> Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service
>>>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving
>>>>>>>>>>>>>>> Bundle (1.0.8)|1.0.8
>>>>>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint
>>>>>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 11|Active | 4|Apache Felix File Install
>>>>>>>>>>>>>>> (3.5.4)|3.5.4
>>>>>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell
>>>>>>>>>>>>>>> (0.12.0)|0.12.0
>>>>>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command
>>>>>>>>>>>>>>> (0.16.0)|0.16.0
>>>>>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime
>>>>>>>>>>>>>>> (0.16.2)|0.16.2
>>>>>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>>>>>>>>>>>> (1.2.8)|1.2.8
>>>>>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin
>>>>>>>>>>>>>>> Service (1.8.8)|1.8.8
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email. The
>>>>>>>>>>>>>>> recipient should check this email and any attachments for the presence of
>>>>>>>>>>>>>>> viruses. The company accepts no liability for any damage caused by any
>>>>>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Warning: Although the company has taken reasonable
>>>>>>>>>>>>>>> precautions to ensure no viruses are present in this email, the company
>>>>>>>>>>>>>>> cannot accept responsibility for any loss or damage arising from the use of
>>>>>>>>>>>>>>> this email or attachments.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Red Hat, Open Source Integration
>>
>> Email: gnodet@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>
>>
>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Matt Sicker <bo...@gmail.com>.
I asked on the Camel mailing list a little while ago if you could add
routes after the CamelContext starts, and I was told that yes, you can. So
at least dynamically adding routes as they start up would work just fine.
I'm not sure about adding Components and other things to the registry,
however.
On 14 July 2016 at 09:43, Kamesh Sampath <ka...@hotmail.com> wrote:
> I did start some work around making a DS solution for Camel using enRoute
> as a base, am not successful yet in making that happen. i have repo here
> https://github.com/kameshsampath/org.workspace7.osgi.enroute.camel. I am
> facing some technical issues in getting it running even the simplest Camel
> route, the inspiration was the original Camel example using Felix SCR's
> http://camel.apache.org/camel-and-scr.html, would be glad to collaborate
> to materialize this if I can get some help and directions from experts.
>
>
> -Kamesh
>
>
> ------------------------------
> From: timothyjward@apache.org
> To: user@aries.apache.org
> Subject: Re: blueprint:cm multiple bundle but same config file
> Date: Wed, 13 Jul 2016 08:34:41 +0000
>
>
> Hi Brad,
>
> I’ve been watching this thread for a while, and you’ve finally managed to
> draw me in :)
>
>
> On 12 Jul 2016, at 17:42, Brad Johnson <br...@mediadriver.com>
> wrote:
>
> Guillaume,
>
> I'm still using Blueprint and have found Camel/SCR to be a pain to work
> with. It provides no tangible benefit if one is using Blueprint for routes
> and dependency injection anyway as it simply introduces one more way of
> configuring things. It was interesting to read the other day that Christian
> seems to have the same impression of the complexity of SCR. I remember
> when I first tried I thought it looked pretty cool but started running into
> problems.
>
>
> So what you’re comparing here isn’t really apples with apples. A long way
> back Camel provided a bunch of Spring XML sugar to make configuring Camel
> simpler. This was obviously a good thing because setting up Camel was (and
> is) hard. To this day people still use the Spring syntax for building their
> Camel routes. OSGi blueprint was effectively a move by Spring to
> standardise the Spring DM container, and so unsurprisingly blueprint looks
> a lot like Spring. Some people did the work to port the Camel Spring
> configuration to OSGi blueprint, and that’s why Camel is easy to use in
> blueprint.
>
> If someone actually spent some time putting together a nice integration
> with SCR then I’m sure that using SCR would be at least as easy as
> blueprint. The problem here is that relatively few SCR developers/users use
> Camel, and the ones that do are just told to “use blueprint”.
>
> That DS is in its second generation and only now getting around to
> transactions is telling. Either it has reached its natural boundaries and
> is now over-reaching or wasn’t full thought out.
>
>
> DS is actually working on its fifth release, and transactions are nowhere
> to be seen. You may be referring to the Transaction Control specification,
> which is separate from DS. They can be used together very effectively, but
> you could equally use Transaction Control with blueprint.
>
> DS is actually one of the “good citizens” of the DI world in that it
> deliberately does less in order to do it well. There’s no dependency
> proxying, no aspects, just the code that you wrote injected with some other
> code that someone wrote.
>
> To me it's a component and service bootstrapping mechanism which
> represents a small portion of the world I work in - transforms, routing,
> EIPs, etc. I've no reason to embrace it or deny it unless it either makes
> my job much easier or I can't live without it. So far adding Camel SCR and
> DS into the middleware just results in one more thing I have to deal with.
>
>
> This is a perfectly acceptable viewpoint. If the fundamental limitations
> of the blueprint model aren’t a problem for you then switching right now is
> almost certainly unnecessary.
>
>
> I think Blueprint works well these days and has come a long way in the
> past 3 years. The Aries team is to be commended for some great work.
>
>
> Aries Blueprint has had a lot of extensions and improvements over the last
> three years. Sadly the same cannot be said for the specifications or other
> implementations. Aries Blueprint is very much the last implementation
> standing, and there has been no effort to standardise the new features (or
> even to try fixing the problems with the original standard). The set of
> RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance is
> very telling.
>
> As far as Aries blueprint is concerned, the main reason that it is still
> alive seems to be the fact that it was included in Karaf, and that Karaf
> provides Camel integration alongside it. Even Karaf itself is starting to
> move to use DS internally, offering blueprint as something for applications
> to use.
>
>
> I’ve been surprised by the near religious zeal of some of the DS
> advocates.
>
>
> Most OSGi developers I know (myself included) who really start to use DS
> consider it to be roughly equivalent to magic. The fact that the model can
> be as simple as it is and yet still flexible, correct and safe is both
> surprising and pleasing. Moving back to “not DS” is usually pretty painful
> and reminds people why they love DS so much.
>
> I'll be interested in seeing the DS semantics and proxies for CDI. Heh.
> Proxies are another technology that I don't care about one way or the other
> as long as things work well and don't require a lot of configuration. So
> it’s great if we can get rid of proxies but not so great if I now have to
> trade that off for configuration of start up order on services to make sure
> everything is running before Camel routes come up.
>
>
> Actually, this is one of the places where DS really shines. If you write a
> DS component properly (i.e. without trying to dig out of the DS lifecycle)
> then startup ordering ceases to be an issue.
>
> Again, someone with a little time and expertise would probably find that
> Camel + DS can be a really effective solution. The problem is finding the
> person who has the time, expertise and inclination…
>
> Tim Ward
>
> Apache Aries PMC Member,
> OSGi IoT Expert Group Chair,
> Author Enterprise OSGi in Action
> timothyjward@apache.org
>
>
>
>
>
>
>
> On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gn...@apache.org>
> wrote:
>
> I can happily review a patch if you're fancy writing one...
>
> And I disagree with the 'blueprint is dead and nobody cares about it
> anymore'. What's dead is the blueprint osgi specification for blueprint,
> not the Aries Blueprint project. I've recently added a bunch of important
> features related to spring in blueprint.
>
> DS also has some drawbacks as it's not extensible at all : this is leading
> the OSGi Alliance to write a new spec for transaction support !!!
>
> I think the CDI+DS extension I've been working on those past weeks could
> bring the best of both world : strong DS semantics for the OSGi bits, but
> extensibility and support for proxies provided by CDI ;-)
>
>
> 2016-07-12 17:24 GMT+02:00 Brad Johnson <br...@mediadriver.com>:
>
> David,
>
> I'm all for multilocation support in blueprint. Can't wait for it. But
> it sounds like your saying blueprint is dead and nobody cares about it
> anymore so it doesn't seem likely to happen anytime soon. It certainly
> wouldn't be relevant to Fuse which uses R4 in any case.
>
> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <
> brad.johnson@mediadriver.com> wrote:
>
> The features file can have statements like this:
>
>
> <configfile finalname="/etc/com.foo.cfg"
> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
> <configfile finalname="/etc/com.bar.cfg"
> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
> ....etc....
> That's off the top of my head so take it with a grain of salt for syntax.
>
> When you run the features install it will overwrite the files in the etc
> directory with the ones in the maven bundle which have now been updated. So
> instead of modifying configuration files in the etc directory you modifying
> them in your Maven configuration project and recompile the bundle and then
> pull it from the repo
> in order to update the values.
>
> But you can still modify them in the etc if you wanted. You just have to
> make sure you have the cm properties set to reload.
>
> <cm:property-placeholder persistent-id="com.foo" update-strategy="reload">
>
> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at
> > wrote:
>
> Brad, if I understand your approach too that would lead to not being able
> to dynamically change common properties in a single config place during
> runtime, as the fill made by maven would be only done once at build time
> right? But at runtime I would need to that as David mention, still n times
> right?
>
> as a use case for instance, with blueprint:cm update-strategy configured
> as 'reload' in combination with felix-fileinstall as directory watcher,
> bundles are reloaded automatically so that when I modify at anytime during
> runtime a property e.g with just a text editor the bundle is initiated
> again with the new property values which is a quite nice feature
>
> best
> Pablo
>
>
> On 12/07/2016 12:31 AM, David Jencks wrote:
>
> I’d like to make sure I understand what you are doing here…. IIUC during
> the build of your project you are generating multiple configuration files
> with the same or similar content, and each of these is loaded into a
> configuration which is bound to a particular bundle location? So, at build
> time you can change all the duplicate properties at once but if you need to
> change them later you have to alter n (== number of duplicate configs)
> independently? Whereas if you had multi-location support (and possibly
> multi-pid support such as DS provides) you could share a single
> Configuration and change the property while the framework was running in
> one place?
>
> thanks
> david jencks
>
> On Jul 11, 2016, at 1:42 PM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
> Pablo,
>
> One possible solution to this problem that I'm currently looking at is
> using a configuration bundle along with my features bundle. In the
> configuration bundle I have all the cfg files and use properties
> placeholders ${value} to set the value for key/value.
>
> In the POM I load properties files using the Maven properties plugin and
> that lets me set a global set of properties values that can be used in
> filling in the cfg values. So if a port or URI is shared across a large
> number of them that automatically gets filled in. The features file can
> then specify the cfg files to install and what name to install them with.
>
> This gets rid of a lot of tedium and by using profiles I should be able to
> switch dev, test and production, and have the properties automatically set
> correctly.
>
> I'd like to modify this a bit so that dev, test and product cfg files are
> all created simultaneously and simply installed in different directories
> inside the configuration bundle. Then by using different features installs
> I can easily switch between the different configurations without having to
> tediously edit each configuration file.
>
> Brad
>
> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> Does Camel/Fuse even support DS? I haven't found any documentation saying
> otherwise. I've only found camel-scr which uses Felix-specific annotations
> and not DS.
>
> On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com>
> wrote:
>
> David,
>
> That is some pretty extreme and wild speculation alright. How does one
> use blueprint to not use OSGi appropriately? In the 5 years I've been
> consulting with Fuse/Karaf/OSGi and going to various clients not one of
> them used or uses DS. Not one. They all use bundles, services, and Camel
> with blueprint. The last time I worked with DS I didn't find it provided
> any serious advantage and added another layer that I'd have to teach my
> clients. Not that I wouldn't consider it or use it if I found a real
> advantage but I haven't.
>
> Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi 4.x
> land much less 5 or 6.
>
> So for Camel are you using the Java DSL?
>
> Brad
>
> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <da...@yahoo.com>
> wrote:
>
> I don’t think karaf is at osgi R4.2 any more, I suggest you look at the
> osgi R5 or R6 config admin spec for “multi location”.
>
> You guys might be using blueprint every day, but there is no OSGI spec
> work to keep it up to date or even specify obviously necessary features
> such as config admin integration. If blueprint is so great why aren’t the
> proponents keeping the spec related to current OSGI? This is a part of my,
> admittedly extreme, theory that use of blueprint is related to not wanting
> to make the app actually use osgi appropriately.
>
> And, the project I work on every day uses DS exclusively and still finds
> plenty of ways to abuse osgi in all sorts of inventive ways :-)
>
> david jencks
>
>
> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com> wrote:
>
> It is in here;
> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>
> A bundle is in aries bound to the pid. So it is actually working as
> expected, bit of
> a hassle since spring-dm allowed it.
>
> And yes selling DS into “regular" organizations is about as easy as
> selling snow in Alaska.
>
> /je
>
> On Jul 7, 2016, at 12:00 PM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
> David,
>
> You live in a very different world than I do. In all the consulting I do
> with Fuse/karaf blueprint is used almost exclusively. I understand DS and
> its uses but also its limits and overhead. It's like telling me one should
> only use Camel Java DSL. That may be one's perspective but that isn't
> everyone's.
>
> Brad
>
> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <da...@yahoo.com>
> wrote:
>
> IMNSHO blueprint is only really plausible if you have a large amount of
> Spring based code and you need to convert it to be sort of osgi-compatible
> really quickly without understanding osgi or the code. Otherwise taking
> the time to understand DS and use it is much more satisfactory. DS
> provides this configuration override ability with support for multiple
> pids, although only one of the pids can turn out to be a factory
> configuration. There’s no obvious way of correlating factory
> configurations, so this restriction makes some sense.
>
> I don’t think there really are any blueprint folks. The cm stuff, while
> obviously required to make the spec remotely plausible, hasn’t made it into
> the spec in the many many years it’s been sitting around.
>
> david jencks
>
> On Jul 7, 2016, at 10:41 AM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
> If I were to sit down with the blueprint folks today to create a wish list
> one thing I'd like to see is for an ability to have a configuration
> hierarchy specified with parent/child relationships much like one has in
> Maven. Have a base configuration file and be able to have another cfg file
> specify that one as its parent. Override properties or add them to the
> child. When the configuration admin fires up it would read up the chain
> and construct the properties.
>
> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
> brad.johnson@mediadriver.com> wrote:
>
> Ray,
>
> If I understand your question right the answer is the Aries extension is
> referencing configuration. In karaf/fuse for example the following:
>
> <cm:property-placeholder persistent-id="com.my.foo"
> update-strategy="reload">
>
> will load properties from etc/com.my.foo.cfg
>
> Installing that file is done either manually or by use of a features file.
>
> Whenever I've attempted to use the PID in more than one bundle it has
> failed and I don't think it is permitted. That's a problem I think and
> something that should be fixed through some other configuration management
> mechanism. Making microservices that might share common properties, for
> example, becomes problematic in that regard and I've resorted to using my
> own OSGi services to overcome that problem.
>
> Brad
>
> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <ra...@liferay.com>
> wrote:
>
> Ok, so after a brief review the cm schema is an Aries extension and it
> doesn't appear to support the location binding.
>
> However, it's unclear to me whether this extension is creating the
> configuration or merely referencing one from outside.
>
> Any Aries gurus can answer that?
>
> - Ray
>
> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <da...@yahoo.com>
> wrote:
>
> I’m not really familiar with blueprint cm but I’d expect that to indicate
> which pid to use to fetch the config from config admin and in the ... how
> to map configuration propertiething blueprint substitution knows about. Is
> that really instructions to create a new configuration and populate it with
> data (what a management agent does)?
>
> david jencks
>
> On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com> wrote:
>
> David, I agree with everything you've said, however this looks like
> blueprint being the agent here:
>
> <cm:property-placeholder persistent-id="my.id" update-strategy="reload">
> ...
> </cm:property-placeholder>
>
> - Ray
>
> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <da...@yahoo.com>
> wrote:
>
> No, blueprint cm shouldn’t really know about the multi-location. The
> management agent that is creating the configuration should be setting the
> bundle location to the multi-location ”?”.
>
> david jencks
>
> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
> wrote:
>
> I see and would it possible to configure which method is invoked from
> Blueprint?
>
> This is how I do it:
>
> <cm:property-placeholder persistent-id="my.id" update-strategy="reload">
> ...
> </cm:property-placeholder>
>
> is there perhaps some blueprint property where I can tune the second
> argument in the createFactoryConfiguration?
>
> Because it looks like the fact of using config admin through blueprint
> binds the PID to the first bundle using it
>
>
> best
> Pablo
>
>
> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>
> As long as configurations are not bound to a bundle they can be used by
> any bundle.
>
> The exception clearly shows that the configuration is bound to a bundle.
>
> Creating an unbound configuration requires passing a "?" as the second
> arguments to getConfiguration/createFactoryConfiguration methods of CM.
>
>
> HTH,
> - Ray
>
> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
> brad.johnson@mediadriver.com> wrote:
>
> I don't think that's possible.
>
> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
> wrote:
>
> Hello All,
>
> Is it possible to use same config file from multiple bundles
> while using Config Admin with blueprint Blueprint? Because, I can't manage
> to do that, I get the following error:
>
> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm.ManagedService,
> id=214, bundle=86/initial@reference:file:../plugin-1/]: No visibility to
> configuration bound to initial@reference:file:../plugin-2/
>
>
> I saw in this jira a bug opened:
> https://issues.jboss.org/browse/ENTESB-3959
>
>
> However, I fear that this is a problem in the aries blueprint
> implementation as I'm not using KARAF nor FUSE, just a plain osgi
> container. Either that or I'm missing some blueprint configuration. I'm
> basically using blueprint:cm
>
>
> As a workaround I can make a config file per bundle that needs it....
>
> As follows the versions and bundles that I'm using related to the
> container (Running on top of Equinox 3.11):
>
> ID|State |Level|Name
> 5|Active | 2|Apache Aries Whiteboard support for JMX
> DynamicMBean services (1.1.5)|1.1.5
> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
> 13|Active | 3|Aries Remote Service Admin Topology Manager
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment
> Bundle (1.0.0)|1.0.0
> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
> 67|Active | 3|Aries Remote Service Admin Service Provider
> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes
> (1.0.0)|1.0.0
> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
> 94|Active | 3|Aries Remote Service Admin Discovery Config
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 97|Active | 3|Aries Remote Service Admin provider TCP
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
> 130|Active | 2|Apache Aries Blueprint Annotation Impl
> (1.0.1)|1.0.1
> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 134|Active | 3|Aries Remote Service Admin Discovery Local
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 138|Active | 3|Aries Remote Service Admin Core
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
> (1.0.8)|1.0.8
> 147|Active | 2|Aries JPA Container blueprint integration for
> Aries blueprint (1.0.4)|1.0.4
>
> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
> 148|Active | 4|Apache Felix Configuration Admin Service
> (1.8.8)|1.8.8
>
> 0|Active | 0|OSGi System Bundle
> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>
>
> --
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email. E-mail transmission cannot be guaranteed to be
> secure or error-free as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The sender
> therefore does not accept liability for any errors or omissions in the
> contents of this message, which arise as a result of e-mail transmission.
>
> Warning: Although the company has taken reasonable precautions to ensure
> no viruses are present in this email, the company cannot accept
> responsibility for any loss or damage arising from the use of this email or
> attachments.
>
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
> (@OSGiAlliance)
>
>
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
> (@OSGiAlliance)
>
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
> (@OSGiAlliance)
>
>
>
>
>
>
>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
>
>
>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
>
--
Matt Sicker <bo...@gmail.com>
RE: blueprint:cm multiple bundle but same config file
Posted by Kamesh Sampath <ka...@hotmail.com>.
I did start some work around making a DS solution for Camel using enRoute as a base, am not successful yet in making that happen. i have repo here https://github.com/kameshsampath/org.workspace7.osgi.enroute.camel. I am facing some technical issues in getting it running even the simplest Camel route, the inspiration was the original Camel example using Felix SCR's http://camel.apache.org/camel-and-scr.html, would be glad to collaborate to materialize this if I can get some help and directions from experts.
-Kamesh
From: timothyjward@apache.org
To: user@aries.apache.org
Subject: Re: blueprint:cm multiple bundle but same config file
Date: Wed, 13 Jul 2016 08:34:41 +0000
Hi Brad,
I’ve been watching this thread for a while, and you’ve finally managed to draw me in :)
On 12 Jul 2016, at 17:42, Brad Johnson <br...@mediadriver.com> wrote:
Guillaume,
I'm still using Blueprint and have found Camel/SCR to be a pain to work with. It provides no tangible benefit if one is using Blueprint for routes and dependency injection anyway as it simply introduces one more way of configuring things. It
was interesting to read the other day that Christian seems to have the same impression of the complexity of SCR. I remember when I first tried I thought it looked pretty cool but started running into problems.
So what you’re comparing here isn’t really apples with apples. A long way back Camel provided a bunch of Spring XML sugar to make configuring Camel simpler. This was obviously a good thing because setting up Camel was (and is) hard. To this day people
still use the Spring syntax for building their Camel routes. OSGi blueprint was effectively a move by Spring to standardise the Spring DM container, and so unsurprisingly blueprint looks a lot like Spring. Some people did the work to port the Camel Spring
configuration to OSGi blueprint, and that’s why Camel is easy to use in blueprint.
If someone actually spent some time putting together a nice integration with SCR then I’m sure that using SCR would be at least as easy as blueprint. The problem here is that relatively few SCR developers/users use Camel, and the ones that do are just
told to “use blueprint”.
That DS is in its second generation and only now getting around to transactions is telling. Either it has reached its natural boundaries and is now over-reaching or wasn’t full thought out.
DS is actually working on its fifth release, and transactions are nowhere to be seen. You may be referring to the Transaction Control specification, which is separate from DS. They can be used together very effectively, but you could equally use Transaction
Control with blueprint.
DS is actually one of the “good citizens” of the DI world in that it deliberately does less in order to do it well. There’s no dependency proxying, no aspects, just the code that you wrote injected with some other code that someone wrote.
To me it's a component and service bootstrapping mechanism which represents a small portion of the world I work in - transforms, routing, EIPs, etc. I've no reason to embrace it or deny it unless it either makes my job much easier or I can't
live without it. So far adding Camel SCR and DS into the middleware just results in one more thing I have to deal with.
This is a perfectly acceptable viewpoint. If the fundamental limitations of the blueprint model aren’t a problem for you then switching right now is almost certainly unnecessary.
I think Blueprint works well these days and has come a long way in the past 3 years. The Aries team is to be commended for some great work.
Aries Blueprint has had a lot of extensions and improvements over the last three years. Sadly the same cannot be said for the specifications or other implementations. Aries Blueprint is very much the last implementation standing, and there has been no
effort to standardise the new features (or even to try fixing the problems with the original standard). The set of RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance is very telling.
As far as Aries blueprint is concerned, the main reason that it is still alive seems to be the fact that it was included in Karaf, and that Karaf provides Camel integration alongside it. Even Karaf itself is starting to move to use DS internally, offering
blueprint as something for applications to use.
I’ve been surprised by the near religious zeal of some of the DS advocates.
Most OSGi developers I know (myself included) who really start to use DS consider it to be roughly equivalent to magic. The fact that the model can be as simple as it is and yet still flexible, correct and safe is both surprising and pleasing. Moving back
to “not DS” is usually pretty painful and reminds people why they love DS so much.
I'll be interested in seeing the DS semantics and proxies for CDI. Heh. Proxies are another technology that I don't care about one way or the other as long as things work well and don't require a lot of configuration. So it’s great if we can
get rid of proxies but not so great if I now have to trade that off for configuration of start up order on services to make sure everything is running before Camel routes come up.
Actually, this is one of the places where DS really shines. If you write a DS component properly (i.e. without trying to dig out of the DS lifecycle) then startup ordering ceases to be an issue.
Again, someone with a little time and expertise would probably find that Camel + DS can be a really effective solution. The problem is finding the person who has the time, expertise and inclination…
Tim Ward
Apache Aries PMC Member,
OSGi IoT Expert Group Chair,
Author Enterprise OSGi in Action
timothyjward@apache.org
On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet
<gn...@apache.org> wrote:
I can happily review a patch if you're fancy writing one...
And I disagree with the 'blueprint is dead and nobody cares about it anymore'. What's dead is the blueprint osgi specification for blueprint, not the Aries Blueprint project. I've recently added a bunch of important features related to spring
in blueprint.
DS also has some drawbacks as it's not extensible at all : this is leading the OSGi Alliance to write a new spec for transaction support !!!
I think the CDI+DS extension I've been working on those past weeks could bring the best of both world : strong DS semantics for the OSGi bits, but extensibility and support for proxies provided by CDI ;-)
2016-07-12 17:24 GMT+02:00 Brad Johnson
<br...@mediadriver.com>:
David,
I'm all for multilocation support in blueprint. Can't wait for it. But it sounds like your saying blueprint is dead and nobody cares about it anymore so it doesn't seem likely to happen anytime soon. It certainly wouldn't be relevant to Fuse
which uses R4 in any case.
On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson
<br...@mediadriver.com> wrote:
The features file can have statements like this:
<configfile finalname="/etc/com.foo.cfg" override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
<configfile finalname="/etc/com.bar.cfg" override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
....etc....
That's off the top of my head so take it with a grain of salt for syntax.
When you run the features install it will overwrite the files in the etc directory with the ones in the maven bundle which have now been updated. So instead of modifying configuration files in the etc
directory you modifying them in your Maven configuration project and recompile the bundle and then pull it from the repo
in order to update the values.
But you can still modify them in the etc if you wanted. You just have to make sure you have the cm properties set to reload.
<cm:property-placeholder persistent-id="com.foo" update-strategy="reload">
On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez
<pa...@faw.jku.at> wrote:
Brad, if I understand your approach too that would lead to not being able to dynamically change common properties in a single config place during runtime, as the fill made by maven would be only done once at build time right? But at runtime I would
need to that as David mention, still n times right?
as a use case for instance, with blueprint:cm update-strategy configured as 'reload' in combination with felix-fileinstall as directory watcher, bundles are reloaded automatically so that when I modify at anytime during runtime a property e.g with
just a text editor the bundle is initiated again with the new property values which is a quite nice feature
best
Pablo
On 12/07/2016 12:31 AM, David Jencks wrote:
I’d like to make sure I understand what you are doing here…. IIUC during the build of your project you are generating multiple configuration files with the same or similar content, and each of these is loaded into a configuration which is bound
to a particular bundle location? So, at build time you can change all the duplicate properties at once but if you need to change them later you have to alter n (== number of duplicate configs) independently? Whereas if you had multi-location support (and
possibly multi-pid support such as DS provides) you could share a single Configuration and change the property while the framework was running in one place?
thanks
david jencks
On Jul 11, 2016, at 1:42 PM, Brad Johnson <br...@mediadriver.com> wrote:
Pablo,
One possible solution to this problem that I'm currently looking at is using a configuration bundle along with my features bundle. In the configuration bundle I have all the cfg files and use properties placeholders ${value} to set the value
for key/value.
In the POM I load properties files using the Maven properties plugin and that lets me set a global set of properties values that can be used in filling in the cfg values. So if a port or URI is shared across a large number of them that automatically
gets filled in. The features file can then specify the cfg files to install and what name to install them with.
This gets rid of a lot of tedium and by using profiles I should be able to switch dev, test and production, and have the properties automatically set correctly.
I'd like to modify this a bit so that dev, test and product cfg files are all created simultaneously and simply installed in different directories inside the configuration bundle. Then by using different features installs I can easily switch
between the different configurations without having to tediously edit each configuration file.
Brad
On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker
<bo...@gmail.com> wrote:
Does Camel/Fuse even support DS? I haven't found any documentation saying otherwise. I've only found camel-scr which uses Felix-specific annotations and not DS.
On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com> wrote:
David,
That is some pretty extreme and wild speculation alright. How does one use blueprint to not use OSGi appropriately? In the 5 years I've been consulting with Fuse/Karaf/OSGi and going to various clients not one of them used or uses DS. Not one.
They all use bundles, services, and Camel with blueprint. The last time I worked with DS I didn't find it provided any serious advantage and added another layer that I'd have to teach my clients. Not that I wouldn't consider it or use it if I found a real
advantage but I haven't.
Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi 4.x land much less 5 or 6.
So for Camel are you using the Java DSL?
Brad
On Thu, Jul 7, 2016 at 1:56 PM, David Jencks
<da...@yahoo.com> wrote:
I don’t think karaf is at osgi R4.2 any more, I suggest you look at the osgi R5 or R6 config admin spec for “multi location”.
You guys might be using blueprint every day, but there is no OSGI spec work to keep it up to date or even specify obviously necessary features such as config admin integration. If blueprint is so great why aren’t the proponents keeping the spec
related to current OSGI? This is a part of my, admittedly extreme, theory that use of blueprint is related to not wanting to make the app actually use osgi appropriately.
And, the project I work on every day uses DS exclusively and still finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
david jencks
On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com> wrote:
It is in here; https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
A bundle is in aries bound to the pid. So it is actually working as expected, bit of
a hassle since spring-dm allowed it.
And yes selling DS into “regular" organizations is about as easy as selling snow in Alaska.
/je
On Jul 7, 2016, at 12:00 PM, Brad Johnson <br...@mediadriver.com> wrote:
David,
You live in a very different world than I do. In all the consulting I do with Fuse/karaf blueprint is used almost exclusively. I understand DS and its uses but also its limits and overhead. It's like telling me one should only use Camel Java
DSL. That may be one's perspective but that isn't everyone's.
Brad
On Thu, Jul 7, 2016 at 12:53 PM, David Jencks
<da...@yahoo.com> wrote:
IMNSHO blueprint is only really plausible if you have a large amount of Spring based code and you need to convert it to be sort of osgi-compatible really quickly without understanding osgi or the code. Otherwise taking the time to understand
DS and use it is much more satisfactory. DS provides this configuration override ability with support for multiple pids, although only one of the pids can turn out to be a factory configuration. There’s no obvious way of correlating factory configurations,
so this restriction makes some sense.
I don’t think there really are any blueprint folks. The cm stuff, while obviously required to make the spec remotely plausible, hasn’t made it into the spec in the many many years it’s been sitting around.
david jencks
On Jul 7, 2016, at 10:41 AM, Brad Johnson <br...@mediadriver.com> wrote:
If I were to sit down with the blueprint folks today to create a wish list one thing I'd like to see is for an ability to have a configuration hierarchy specified with parent/child relationships much like one has in Maven. Have a base
configuration file and be able to have another cfg file specify that one as its parent. Override properties or add them to the child. When the configuration admin fires up it would read up the chain and construct the properties.
On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson
<br...@mediadriver.com> wrote:
Ray,
If I understand your question right the answer is the Aries extension is referencing configuration. In karaf/fuse for example the following:
<cm:property-placeholder persistent-id="com.my.foo" update-strategy="reload">
will load properties from etc/com.my.foo.cfg
Installing that file is done either manually or by use of a features file.
Whenever I've attempted to use the PID in more than one bundle it has failed and I don't think it is permitted. That's a problem I think and something that should be fixed through some other configuration management mechanism. Making microservices
that might share common properties, for example, becomes problematic in that regard and I've resorted to using my own OSGi services to overcome that problem.
Brad
On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge
<ra...@liferay.com> wrote:
Ok, so after a brief review the cm schema is an Aries extension and it doesn't appear to support the location binding.
However, it's unclear to me whether this extension is creating the configuration or merely referencing one from outside.
Any Aries gurus can answer that?
- Ray
On Thu, Jul 7, 2016 at 11:29 AM, David Jencks
<da...@yahoo.com> wrote:
I’m not really familiar with blueprint cm but I’d expect that to indicate which pid to use to fetch the config from config admin and in the ... how to map configuration propertiething blueprint substitution knows about. Is that really instructions
to create a new configuration and populate it with data (what a management agent does)?
david jencks
On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com> wrote:
David, I agree with everything you've said, however this looks like blueprint being the agent here:
<cm:property-placeholder persistent-id="my.id" update-strategy="reload">
...
</cm:property-placeholder>
- Ray
On Thu, Jul 7, 2016 at 11:18 AM, David Jencks
<da...@yahoo.com> wrote:
No, blueprint cm shouldn’t really know about the multi-location. The management agent that is creating the configuration should be setting the bundle location to the multi-location ”?”.
david jencks
On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at> wrote:
I see and would it possible to configure which method is invoked from Blueprint?
This is how I do it:
<cm:property-placeholder persistent-id="my.id" update-strategy="reload">
...
</cm:property-placeholder>
is there perhaps some blueprint property where I can tune the second argument in the createFactoryConfiguration?
Because it looks like the fact of using config admin through blueprint binds the PID to the first bundle using it
best
Pablo
On 07/07/2016 4:41 PM, Raymond Auge wrote:
As long as configurations are not bound to a bundle they can be used by any bundle.
The exception clearly shows that the configuration is bound to a bundle.
Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
HTH,
- Ray
On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson
<br...@mediadriver.com> wrote:
I don't think that's possible.
On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez
<pa...@faw.jku.at> wrote:
Hello All,
Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm.ManagedService, id=214,
bundle=86/initial@reference:file:../plugin-1/]: No visibility to configuration bound to
initial@reference:file:../plugin-2/
I saw in this jira a bug opened:
https://issues.jboss.org/browse/ENTESB-3959
However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
As a workaround I can make a config file per bundle that needs it....
As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
ID|State |Level|Name
5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
--
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission
cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this
message, which arise as a result of e-mail transmission.
Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay,
Inc. (@Liferay)
Board Member & EEG Co-Chair,
OSGi Alliance (@OSGiAlliance)
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay,
Inc. (@Liferay)
Board Member & EEG Co-Chair,
OSGi Alliance (@OSGiAlliance)
--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay,
Inc. (@Liferay)
Board Member & EEG Co-Chair,
OSGi Alliance (@OSGiAlliance)
--
Matt Sicker <bo...@gmail.com>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: blueprint:cm multiple bundle but same config file
Posted by Timothy Ward <ti...@apache.org>.
Hi Brad,
I’ve been watching this thread for a while, and you’ve finally managed to draw me in :)
On 12 Jul 2016, at 17:42, Brad Johnson <br...@mediadriver.com>> wrote:
Guillaume,
I'm still using Blueprint and have found Camel/SCR to be a pain to work with. It provides no tangible benefit if one is using Blueprint for routes and dependency injection anyway as it simply introduces one more way of configuring things. It was interesting to read the other day that Christian seems to have the same impression of the complexity of SCR. I remember when I first tried I thought it looked pretty cool but started running into problems.
So what you’re comparing here isn’t really apples with apples. A long way back Camel provided a bunch of Spring XML sugar to make configuring Camel simpler. This was obviously a good thing because setting up Camel was (and is) hard. To this day people still use the Spring syntax for building their Camel routes. OSGi blueprint was effectively a move by Spring to standardise the Spring DM container, and so unsurprisingly blueprint looks a lot like Spring. Some people did the work to port the Camel Spring configuration to OSGi blueprint, and that’s why Camel is easy to use in blueprint.
If someone actually spent some time putting together a nice integration with SCR then I’m sure that using SCR would be at least as easy as blueprint. The problem here is that relatively few SCR developers/users use Camel, and the ones that do are just told to “use blueprint”.
That DS is in its second generation and only now getting around to transactions is telling. Either it has reached its natural boundaries and is now over-reaching or wasn’t full thought out.
DS is actually working on its fifth release, and transactions are nowhere to be seen. You may be referring to the Transaction Control specification, which is separate from DS. They can be used together very effectively, but you could equally use Transaction Control with blueprint.
DS is actually one of the “good citizens” of the DI world in that it deliberately does less in order to do it well. There’s no dependency proxying, no aspects, just the code that you wrote injected with some other code that someone wrote.
To me it's a component and service bootstrapping mechanism which represents a small portion of the world I work in - transforms, routing, EIPs, etc. I've no reason to embrace it or deny it unless it either makes my job much easier or I can't live without it. So far adding Camel SCR and DS into the middleware just results in one more thing I have to deal with.
This is a perfectly acceptable viewpoint. If the fundamental limitations of the blueprint model aren’t a problem for you then switching right now is almost certainly unnecessary.
I think Blueprint works well these days and has come a long way in the past 3 years. The Aries team is to be commended for some great work.
Aries Blueprint has had a lot of extensions and improvements over the last three years. Sadly the same cannot be said for the specifications or other implementations. Aries Blueprint is very much the last implementation standing, and there has been no effort to standardise the new features (or even to try fixing the problems with the original standard). The set of RFPs/RFCs for blueprint that have been sitting idle in the OSGi Alliance is very telling.
As far as Aries blueprint is concerned, the main reason that it is still alive seems to be the fact that it was included in Karaf, and that Karaf provides Camel integration alongside it. Even Karaf itself is starting to move to use DS internally, offering blueprint as something for applications to use.
I’ve been surprised by the near religious zeal of some of the DS advocates.
Most OSGi developers I know (myself included) who really start to use DS consider it to be roughly equivalent to magic. The fact that the model can be as simple as it is and yet still flexible, correct and safe is both surprising and pleasing. Moving back to “not DS” is usually pretty painful and reminds people why they love DS so much.
I'll be interested in seeing the DS semantics and proxies for CDI. Heh. Proxies are another technology that I don't care about one way or the other as long as things work well and don't require a lot of configuration. So it’s great if we can get rid of proxies but not so great if I now have to trade that off for configuration of start up order on services to make sure everything is running before Camel routes come up.
Actually, this is one of the places where DS really shines. If you write a DS component properly (i.e. without trying to dig out of the DS lifecycle) then startup ordering ceases to be an issue.
Again, someone with a little time and expertise would probably find that Camel + DS can be a really effective solution. The problem is finding the person who has the time, expertise and inclination…
Tim Ward
Apache Aries PMC Member,
OSGi IoT Expert Group Chair,
Author Enterprise OSGi in Action
timothyjward@apache.org<ma...@apache.org>
On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gn...@apache.org>> wrote:
I can happily review a patch if you're fancy writing one...
And I disagree with the 'blueprint is dead and nobody cares about it anymore'. What's dead is the blueprint osgi specification for blueprint, not the Aries Blueprint project. I've recently added a bunch of important features related to spring in blueprint.
DS also has some drawbacks as it's not extensible at all : this is leading the OSGi Alliance to write a new spec for transaction support !!!
I think the CDI+DS extension I've been working on those past weeks could bring the best of both world : strong DS semantics for the OSGi bits, but extensibility and support for proxies provided by CDI ;-)
2016-07-12 17:24 GMT+02:00 Brad Johnson <br...@mediadriver.com>>:
David,
I'm all for multilocation support in blueprint. Can't wait for it. But it sounds like your saying blueprint is dead and nobody cares about it anymore so it doesn't seem likely to happen anytime soon. It certainly wouldn't be relevant to Fuse which uses R4 in any case.
On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <br...@mediadriver.com>> wrote:
The features file can have statements like this:
<configfile finalname="/etc/com.foo.cfg" override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
<configfile finalname="/etc/com.bar.cfg" override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
....etc....
That's off the top of my head so take it with a grain of salt for syntax.
When you run the features install it will overwrite the files in the etc directory with the ones in the maven bundle which have now been updated. So instead of modifying configuration files in the etc directory you modifying them in your Maven configuration project and recompile the bundle and then pull it from the repo
in order to update the values.
But you can still modify them in the etc if you wanted. You just have to make sure you have the cm properties set to reload.
<cm:property-placeholder persistent-id="com.foo" update-strategy="reload">
On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <pa...@faw.jku.at>> wrote:
Brad, if I understand your approach too that would lead to not being able to dynamically change common properties in a single config place during runtime, as the fill made by maven would be only done once at build time right? But at runtime I would need to that as David mention, still n times right?
as a use case for instance, with blueprint:cm update-strategy configured as 'reload' in combination with felix-fileinstall as directory watcher, bundles are reloaded automatically so that when I modify at anytime during runtime a property e.g with just a text editor the bundle is initiated again with the new property values which is a quite nice feature
best
Pablo
On 12/07/2016 12:31 AM, David Jencks wrote:
I’d like to make sure I understand what you are doing here…. IIUC during the build of your project you are generating multiple configuration files with the same or similar content, and each of these is loaded into a configuration which is bound to a particular bundle location? So, at build time you can change all the duplicate properties at once but if you need to change them later you have to alter n (== number of duplicate configs) independently? Whereas if you had multi-location support (and possibly multi-pid support such as DS provides) you could share a single Configuration and change the property while the framework was running in one place?
thanks
david jencks
On Jul 11, 2016, at 1:42 PM, Brad Johnson <br...@mediadriver.com>> wrote:
Pablo,
One possible solution to this problem that I'm currently looking at is using a configuration bundle along with my features bundle. In the configuration bundle I have all the cfg files and use properties placeholders ${value} to set the value for key/value.
In the POM I load properties files using the Maven properties plugin and that lets me set a global set of properties values that can be used in filling in the cfg values. So if a port or URI is shared across a large number of them that automatically gets filled in. The features file can then specify the cfg files to install and what name to install them with.
This gets rid of a lot of tedium and by using profiles I should be able to switch dev, test and production, and have the properties automatically set correctly.
I'd like to modify this a bit so that dev, test and product cfg files are all created simultaneously and simply installed in different directories inside the configuration bundle. Then by using different features installs I can easily switch between the different configurations without having to tediously edit each configuration file.
Brad
On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com>> wrote:
Does Camel/Fuse even support DS? I haven't found any documentation saying otherwise. I've only found camel-scr which uses Felix-specific annotations and not DS.
On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com>> wrote:
David,
That is some pretty extreme and wild speculation alright. How does one use blueprint to not use OSGi appropriately? In the 5 years I've been consulting with Fuse/Karaf/OSGi and going to various clients not one of them used or uses DS. Not one. They all use bundles, services, and Camel with blueprint. The last time I worked with DS I didn't find it provided any serious advantage and added another layer that I'd have to teach my clients. Not that I wouldn't consider it or use it if I found a real advantage but I haven't.
Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi 4.x land much less 5 or 6.
So for Camel are you using the Java DSL?
Brad
On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <da...@yahoo.com>> wrote:
I don’t think karaf is at osgi R4.2 any more, I suggest you look at the osgi R5 or R6 config admin spec for “multi location”.
You guys might be using blueprint every day, but there is no OSGI spec work to keep it up to date or even specify obviously necessary features such as config admin integration. If blueprint is so great why aren’t the proponents keeping the spec related to current OSGI? This is a part of my, admittedly extreme, theory that use of blueprint is related to not wanting to make the app actually use osgi appropriately.
And, the project I work on every day uses DS exclusively and still finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
david jencks
On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com>> wrote:
It is in here; https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
A bundle is in aries bound to the pid. So it is actually working as expected, bit of
a hassle since spring-dm allowed it.
And yes selling DS into “regular" organizations is about as easy as selling snow in Alaska.
/je
On Jul 7, 2016, at 12:00 PM, Brad Johnson <br...@mediadriver.com>> wrote:
David,
You live in a very different world than I do. In all the consulting I do with Fuse/karaf blueprint is used almost exclusively. I understand DS and its uses but also its limits and overhead. It's like telling me one should only use Camel Java DSL. That may be one's perspective but that isn't everyone's.
Brad
On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <da...@yahoo.com>> wrote:
IMNSHO blueprint is only really plausible if you have a large amount of Spring based code and you need to convert it to be sort of osgi-compatible really quickly without understanding osgi or the code. Otherwise taking the time to understand DS and use it is much more satisfactory. DS provides this configuration override ability with support for multiple pids, although only one of the pids can turn out to be a factory configuration. There’s no obvious way of correlating factory configurations, so this restriction makes some sense.
I don’t think there really are any blueprint folks. The cm stuff, while obviously required to make the spec remotely plausible, hasn’t made it into the spec in the many many years it’s been sitting around.
david jencks
On Jul 7, 2016, at 10:41 AM, Brad Johnson <br...@mediadriver.com>> wrote:
If I were to sit down with the blueprint folks today to create a wish list one thing I'd like to see is for an ability to have a configuration hierarchy specified with parent/child relationships much like one has in Maven. Have a base configuration file and be able to have another cfg file specify that one as its parent. Override properties or add them to the child. When the configuration admin fires up it would read up the chain and construct the properties.
On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <br...@mediadriver.com>> wrote:
Ray,
If I understand your question right the answer is the Aries extension is referencing configuration. In karaf/fuse for example the following:
<cm:property-placeholder persistent-id="com.my.foo" update-strategy="reload">
will load properties from etc/com.my.foo.cfg
Installing that file is done either manually or by use of a features file.
Whenever I've attempted to use the PID in more than one bundle it has failed and I don't think it is permitted. That's a problem I think and something that should be fixed through some other configuration management mechanism. Making microservices that might share common properties, for example, becomes problematic in that regard and I've resorted to using my own OSGi services to overcome that problem.
Brad
On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <ra...@liferay.com>> wrote:
Ok, so after a brief review the cm schema is an Aries extension and it doesn't appear to support the location binding.
However, it's unclear to me whether this extension is creating the configuration or merely referencing one from outside.
Any Aries gurus can answer that?
- Ray
On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <da...@yahoo.com>> wrote:
I’m not really familiar with blueprint cm but I’d expect that to indicate which pid to use to fetch the config from config admin and in the ... how to map configuration propertiething blueprint substitution knows about. Is that really instructions to create a new configuration and populate it with data (what a management agent does)?
david jencks
On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com>> wrote:
David, I agree with everything you've said, however this looks like blueprint being the agent here:
<cm:property-placeholder persistent-id="my.id<http://my.id/>" update-strategy="reload">
...
</cm:property-placeholder>
- Ray
On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <da...@yahoo.com>> wrote:
No, blueprint cm shouldn’t really know about the multi-location. The management agent that is creating the configuration should be setting the bundle location to the multi-location ”?”.
david jencks
On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at>> wrote:
I see and would it possible to configure which method is invoked from Blueprint?
This is how I do it:
<cm:property-placeholder persistent-id="my.id<http://my.id/>" update-strategy="reload">
...
</cm:property-placeholder>
is there perhaps some blueprint property where I can tune the second argument in the createFactoryConfiguration?
Because it looks like the fact of using config admin through blueprint binds the PID to the first bundle using it
best
Pablo
On 07/07/2016 4:41 PM, Raymond Auge wrote:
As long as configurations are not bound to a bundle they can be used by any bundle.
The exception clearly shows that the configuration is bound to a bundle.
Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
HTH,
- Ray
On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <br...@mediadriver.com>> wrote:
I don't think that's possible.
On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pa...@faw.jku.at>> wrote:
Hello All,
Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm<http://org.osgi.service.cm/>.ManagedService, id=214, bundle=86/initial@reference:file:../plugin-1/<mailto:bundle=86/initial@reference:file:../plugin-1/>]: No visibility to configuration bound to initial@reference:file:../plugin-2/<mailto:initial@reference:file:../plugin-2/>
I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959
However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
As a workaround I can make a config file per bundle that needs it....
As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
ID|State |Level|Name
5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
--
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
--
Raymond Augé<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect Liferay, Inc.<http://www.liferay.com/> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance<http://osgi.org/> (@OSGiAlliance)
--
Raymond Augé<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect Liferay, Inc.<http://www.liferay.com/> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance<http://osgi.org/> (@OSGiAlliance)
--
Raymond Augé<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect Liferay, Inc.<http://www.liferay.com/> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance<http://osgi.org/> (@OSGiAlliance)
--
Matt Sicker <bo...@gmail.com>>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com<ma...@redhat.com>
Web: http://fusesource.com<http://fusesource.com/>
Blog: http://gnodet.blogspot.com/
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
Guillaume,
I'm still using Blueprint and have found Camel/SCR to be a pain to work
with. It provides no tangible benefit if one is using Blueprint for routes
and dependency injection anyway as it simply introduces one more way of
configuring things. It was interesting to read the other day that Christian
seems to have the same impression of the complexity of SCR. I remember
when I first tried I thought it looked pretty cool but started running into
problems. That DS is in its second generation and only now getting around
to transactions is telling. Either it has reached its natural boundaries
and is now over-reaching or wasn't full thought out. To me it's a
component and service bootstrapping mechanism which represents a small
portion of the world I work in - transforms, routing, EIPs, etc. I've no
reason to embrace it or deny it unless it either makes my job much easier
or I can't live without it. So far adding Camel SCR and DS into the
middleware just results in one more thing I have to deal with.
I think Blueprint works well these days and has come a long way in the past
3 years. The Aries team is to be commended for some great work. I've been
surprised by the near religious zeal of some of the DS advocates. I'll be
interested in seeing the DS semantics and proxies for CDI. Heh. Proxies are
another technology that I don't care about one way or the other as long as
things work well and don't require a lot of configuration. So it's great
if we can get rid of proxies but not so great if I now have to trade that
off for configuration of start up order on services to make sure everything
is running before Camel routes come up.
On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gn...@apache.org> wrote:
> I can happily review a patch if you're fancy writing one...
>
> And I disagree with the 'blueprint is dead and nobody cares about it
> anymore'. What's dead is the blueprint osgi specification for blueprint,
> not the Aries Blueprint project. I've recently added a bunch of important
> features related to spring in blueprint.
>
> DS also has some drawbacks as it's not extensible at all : this is leading
> the OSGi Alliance to write a new spec for transaction support !!!
>
> I think the CDI+DS extension I've been working on those past weeks could
> bring the best of both world : strong DS semantics for the OSGi bits, but
> extensibility and support for proxies provided by CDI ;-)
>
>
> 2016-07-12 17:24 GMT+02:00 Brad Johnson <br...@mediadriver.com>:
>
>> David,
>>
>> I'm all for multilocation support in blueprint. Can't wait for it. But
>> it sounds like your saying blueprint is dead and nobody cares about it
>> anymore so it doesn't seem likely to happen anytime soon. It certainly
>> wouldn't be relevant to Fuse which uses R4 in any case.
>>
>> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <
>> brad.johnson@mediadriver.com> wrote:
>>
>>> The features file can have statements like this:
>>>
>>>
>>> <configfile finalname="/etc/com.foo.cfg"
>>> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
>>> <configfile finalname="/etc/com.bar.cfg"
>>> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
>>> ....etc....
>>> That's off the top of my head so take it with a grain of salt for syntax.
>>>
>>> When you run the features install it will overwrite the files in the etc
>>> directory with the ones in the maven bundle which have now been updated. So
>>> instead of modifying configuration files in the etc directory you modifying
>>> them in your Maven configuration project and recompile the bundle and then
>>> pull it from the repo
>>> in order to update the values.
>>>
>>> But you can still modify them in the etc if you wanted. You just have to
>>> make sure you have the cm properties set to reload.
>>>
>>> <cm:property-placeholder persistent-id="com.foo"
>>> update-strategy="reload">
>>>
>>> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <
>>> pablo.gomez@faw.jku.at> wrote:
>>>
>>>> Brad, if I understand your approach too that would lead to not being
>>>> able to dynamically change common properties in a single config place
>>>> during runtime, as the fill made by maven would be only done once at build
>>>> time right? But at runtime I would need to that as David mention, still n
>>>> times right?
>>>>
>>>> as a use case for instance, with blueprint:cm update-strategy
>>>> configured as 'reload' in combination with felix-fileinstall as directory
>>>> watcher, bundles are reloaded automatically so that when I modify at
>>>> anytime during runtime a property e.g with just a text editor the bundle is
>>>> initiated again with the new property values which is a quite nice feature
>>>>
>>>> best
>>>>
>>>> Pablo
>>>>
>>>> On 12/07/2016 12:31 AM, David Jencks wrote:
>>>>
>>>> I’d like to make sure I understand what you are doing here…. IIUC
>>>> during the build of your project you are generating multiple configuration
>>>> files with the same or similar content, and each of these is loaded into a
>>>> configuration which is bound to a particular bundle location? So, at build
>>>> time you can change all the duplicate properties at once but if you need to
>>>> change them later you have to alter n (== number of duplicate configs)
>>>> independently? Whereas if you had multi-location support (and possibly
>>>> multi-pid support such as DS provides) you could share a single
>>>> Configuration and change the property while the framework was running in
>>>> one place?
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <br...@mediadriver.com>
>>>> wrote:
>>>>
>>>> Pablo,
>>>>
>>>> One possible solution to this problem that I'm currently looking at is
>>>> using a configuration bundle along with my features bundle. In the
>>>> configuration bundle I have all the cfg files and use properties
>>>> placeholders ${value} to set the value for key/value.
>>>>
>>>> In the POM I load properties files using the Maven properties plugin
>>>> and that lets me set a global set of properties values that can be used in
>>>> filling in the cfg values. So if a port or URI is shared across a large
>>>> number of them that automatically gets filled in. The features file can
>>>> then specify the cfg files to install and what name to install them with.
>>>>
>>>> This gets rid of a lot of tedium and by using profiles I should be able
>>>> to switch dev, test and production, and have the properties automatically
>>>> set correctly.
>>>>
>>>> I'd like to modify this a bit so that dev, test and product cfg files
>>>> are all created simultaneously and simply installed in different
>>>> directories inside the configuration bundle. Then by using different
>>>> features installs I can easily switch between the different configurations
>>>> without having to tediously edit each configuration file.
>>>>
>>>> Brad
>>>>
>>>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>>> Does Camel/Fuse even support DS? I haven't found any documentation
>>>>> saying otherwise. I've only found camel-scr which uses Felix-specific
>>>>> annotations and not DS.
>>>>>
>>>>> On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com>
>>>>> wrote:
>>>>>
>>>>>> David,
>>>>>>
>>>>>> That is some pretty extreme and wild speculation alright. How does
>>>>>> one use blueprint to not use OSGi appropriately? In the 5 years I've been
>>>>>> consulting with Fuse/Karaf/OSGi and going to various clients not one of
>>>>>> them used or uses DS. Not one. They all use bundles, services, and Camel
>>>>>> with blueprint. The last time I worked with DS I didn't find it provided
>>>>>> any serious advantage and added another layer that I'd have to teach my
>>>>>> clients. Not that I wouldn't consider it or use it if I found a real
>>>>>> advantage but I haven't.
>>>>>>
>>>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi
>>>>>> 4.x land much less 5 or 6.
>>>>>>
>>>>>> So for Camel are you using the Java DSL?
>>>>>>
>>>>>> Brad
>>>>>>
>>>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <da...@yahoo.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you look at
>>>>>>> the osgi R5 or R6 config admin spec for “multi location”.
>>>>>>>
>>>>>>> You guys might be using blueprint every day, but there is no OSGI
>>>>>>> spec work to keep it up to date or even specify obviously necessary
>>>>>>> features such as config admin integration. If blueprint is so great why
>>>>>>> aren’t the proponents keeping the spec related to current OSGI? This is a
>>>>>>> part of my, admittedly extreme, theory that use of blueprint is related to
>>>>>>> not wanting to make the app actually use osgi appropriately.
>>>>>>>
>>>>>>> And, the project I work on every day uses DS exclusively and still
>>>>>>> finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>>>>>
>>>>>>> david jencks
>>>>>>>
>>>>>>>
>>>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> It is in here;
>>>>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>>>>>
>>>>>>> A bundle is in aries bound to the pid. So it is actually working as
>>>>>>> expected, bit of
>>>>>>> a hassle since spring-dm allowed it.
>>>>>>>
>>>>>>> And yes selling DS into “regular" organizations is about as easy as
>>>>>>> selling snow in Alaska.
>>>>>>>
>>>>>>> /je
>>>>>>>
>>>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <
>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>
>>>>>>> David,
>>>>>>>
>>>>>>> You live in a very different world than I do. In all the consulting
>>>>>>> I do with Fuse/karaf blueprint is used almost exclusively. I understand DS
>>>>>>> and its uses but also its limits and overhead. It's like telling me one
>>>>>>> should only use Camel Java DSL. That may be one's perspective but that
>>>>>>> isn't everyone's.
>>>>>>>
>>>>>>> Brad
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <
>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>
>>>>>>>> IMNSHO blueprint is only really plausible if you have a large
>>>>>>>> amount of Spring based code and you need to convert it to be sort of
>>>>>>>> osgi-compatible really quickly without understanding osgi or the code.
>>>>>>>> Otherwise taking the time to understand DS and use it is much more
>>>>>>>> satisfactory. DS provides this configuration override ability with support
>>>>>>>> for multiple pids, although only one of the pids can turn out to be a
>>>>>>>> factory configuration. There’s no obvious way of correlating factory
>>>>>>>> configurations, so this restriction makes some sense.
>>>>>>>>
>>>>>>>> I don’t think there really are any blueprint folks. The cm stuff,
>>>>>>>> while obviously required to make the spec remotely plausible, hasn’t made
>>>>>>>> it into the spec in the many many years it’s been sitting around.
>>>>>>>>
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <
>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>
>>>>>>>> If I were to sit down with the blueprint folks today to create a
>>>>>>>> wish list one thing I'd like to see is for an ability to have a
>>>>>>>> configuration hierarchy specified with parent/child relationships much like
>>>>>>>> one has in Maven. Have a base configuration file and be able to have
>>>>>>>> another cfg file specify that one as its parent. Override properties or add
>>>>>>>> them to the child. When the configuration admin fires up it would read up
>>>>>>>> the chain and construct the properties.
>>>>>>>>
>>>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>
>>>>>>>>> Ray,
>>>>>>>>>
>>>>>>>>> If I understand your question right the answer is the Aries
>>>>>>>>> extension is referencing configuration. In karaf/fuse for example the
>>>>>>>>> following:
>>>>>>>>>
>>>>>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>>>>>> update-strategy="reload">
>>>>>>>>>
>>>>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>>>>
>>>>>>>>> Installing that file is done either manually or by use of a
>>>>>>>>> features file.
>>>>>>>>>
>>>>>>>>> Whenever I've attempted to use the PID in more than one bundle it
>>>>>>>>> has failed and I don't think it is permitted. That's a problem I think and
>>>>>>>>> something that should be fixed through some other configuration management
>>>>>>>>> mechanism. Making microservices that might share common properties, for
>>>>>>>>> example, becomes problematic in that regard and I've resorted to using my
>>>>>>>>> own OSGi services to overcome that problem.
>>>>>>>>>
>>>>>>>>> Brad
>>>>>>>>>
>>>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>
>>>>>>>>>> Ok, so after a brief review the cm schema is an Aries extension
>>>>>>>>>> and it doesn't appear to support the location binding.
>>>>>>>>>>
>>>>>>>>>> However, it's unclear to me whether this extension is creating
>>>>>>>>>> the configuration or merely referencing one from outside.
>>>>>>>>>>
>>>>>>>>>> Any Aries gurus can answer that?
>>>>>>>>>>
>>>>>>>>>> - Ray
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <
>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I’m not really familiar with blueprint cm but I’d expect that to
>>>>>>>>>>> indicate which pid to use to fetch the config from config admin and in the
>>>>>>>>>>> ... how to map configuration propertiething blueprint substitution knows
>>>>>>>>>>> about. Is that really instructions to create a new configuration and
>>>>>>>>>>> populate it with data (what a management agent does)?
>>>>>>>>>>>
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <
>>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> David, I agree with everything you've said, however this looks
>>>>>>>>>>> like blueprint being the agent here:
>>>>>>>>>>>
>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>> ...
>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>
>>>>>>>>>>> - Ray
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> No, blueprint cm shouldn’t really know about the
>>>>>>>>>>>> multi-location. The management agent that is creating the configuration
>>>>>>>>>>>> should be setting the bundle location to the multi-location ”?”.
>>>>>>>>>>>>
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I see and would it possible to configure which method is
>>>>>>>>>>>> invoked from Blueprint?
>>>>>>>>>>>>
>>>>>>>>>>>> This is how I do it:
>>>>>>>>>>>>
>>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>>> ...
>>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>>
>>>>>>>>>>>> is there perhaps some blueprint property where I can tune the
>>>>>>>>>>>> second argument in the createFactoryConfiguration?
>>>>>>>>>>>>
>>>>>>>>>>>> Because it looks like the fact of using config admin through
>>>>>>>>>>>> blueprint binds the PID to the first bundle using it
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> best
>>>>>>>>>>>> Pablo
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> As long as configurations are not bound to a bundle they can be
>>>>>>>>>>>> used by any bundle.
>>>>>>>>>>>>
>>>>>>>>>>>> The exception clearly shows that the configuration is bound to
>>>>>>>>>>>> a bundle.
>>>>>>>>>>>>
>>>>>>>>>>>> Creating an unbound configuration requires passing a "?" as the
>>>>>>>>>>>> second arguments to getConfiguration/createFactoryConfiguration methods of
>>>>>>>>>>>> CM.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> HTH,
>>>>>>>>>>>> - Ray
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is it possible to use same config file from
>>>>>>>>>>>>>> multiple bundles while using Config Admin with blueprint Blueprint?
>>>>>>>>>>>>>> Because, I can't manage to do that, I get the following error:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No
>>>>>>>>>>>>>> visibility to configuration bound to
>>>>>>>>>>>>>> initial@reference:file:../plugin-2/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, I fear that this is a problem in the aries blueprint
>>>>>>>>>>>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As a workaround I can make a config file per bundle that
>>>>>>>>>>>>>> needs it....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As follows the versions and bundles that I'm using related to
>>>>>>>>>>>>>> the container (Running on top of Equinox 3.11):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for
>>>>>>>>>>>>>> JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology
>>>>>>>>>>>>>> Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>>>> Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM
>>>>>>>>>>>>>> (1.0.7)|1.0.7
>>>>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core
>>>>>>>>>>>>>> (1.5.0)|1.5.0
>>>>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core
>>>>>>>>>>>>>> Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service
>>>>>>>>>>>>>> Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>>>> (1.1.1)|1.1.1
>>>>>>>>>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy
>>>>>>>>>>>>>> Runtimes (1.0.0)|1.0.0
>>>>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>>>> Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin provider
>>>>>>>>>>>>>> TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>>>> (2.1.0)|2.1.0
>>>>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation
>>>>>>>>>>>>>> Impl (1.0.1)|1.0.1
>>>>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>>>> Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>>>> Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service
>>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving
>>>>>>>>>>>>>> Bundle (1.0.8)|1.0.8
>>>>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint
>>>>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 11|Active | 4|Apache Felix File Install
>>>>>>>>>>>>>> (3.5.4)|3.5.4
>>>>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell
>>>>>>>>>>>>>> (0.12.0)|0.12.0
>>>>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command
>>>>>>>>>>>>>> (0.16.0)|0.16.0
>>>>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime
>>>>>>>>>>>>>> (0.16.2)|0.16.2
>>>>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>>>>>>>>>>> (1.2.8)|1.2.8
>>>>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin
>>>>>>>>>>>>>> Service (1.8.8)|1.8.8
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email. The
>>>>>>>>>>>>>> recipient should check this email and any attachments for the presence of
>>>>>>>>>>>>>> viruses. The company accepts no liability for any damage caused by any
>>>>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Warning: Although the company has taken reasonable
>>>>>>>>>>>>>> precautions to ensure no viruses are present in this email, the company
>>>>>>>>>>>>>> cannot accept responsibility for any loss or damage arising from the use of
>>>>>>>>>>>>>> this email or attachments.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> *Raymond Augé*
>>>>>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>> (@rotty3000)
>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Guillaume Nodet <gn...@apache.org>.
I can happily review a patch if you're fancy writing one...
And I disagree with the 'blueprint is dead and nobody cares about it
anymore'. What's dead is the blueprint osgi specification for blueprint,
not the Aries Blueprint project. I've recently added a bunch of important
features related to spring in blueprint.
DS also has some drawbacks as it's not extensible at all : this is leading
the OSGi Alliance to write a new spec for transaction support !!!
I think the CDI+DS extension I've been working on those past weeks could
bring the best of both world : strong DS semantics for the OSGi bits, but
extensibility and support for proxies provided by CDI ;-)
2016-07-12 17:24 GMT+02:00 Brad Johnson <br...@mediadriver.com>:
> David,
>
> I'm all for multilocation support in blueprint. Can't wait for it. But
> it sounds like your saying blueprint is dead and nobody cares about it
> anymore so it doesn't seem likely to happen anytime soon. It certainly
> wouldn't be relevant to Fuse which uses R4 in any case.
>
> On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <
> brad.johnson@mediadriver.com> wrote:
>
>> The features file can have statements like this:
>>
>>
>> <configfile finalname="/etc/com.foo.cfg"
>> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
>> <configfile finalname="/etc/com.bar.cfg"
>> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
>> ....etc....
>> That's off the top of my head so take it with a grain of salt for syntax.
>>
>> When you run the features install it will overwrite the files in the etc
>> directory with the ones in the maven bundle which have now been updated. So
>> instead of modifying configuration files in the etc directory you modifying
>> them in your Maven configuration project and recompile the bundle and then
>> pull it from the repo
>> in order to update the values.
>>
>> But you can still modify them in the etc if you wanted. You just have to
>> make sure you have the cm properties set to reload.
>>
>> <cm:property-placeholder persistent-id="com.foo" update-strategy="reload">
>>
>> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <
>> pablo.gomez@faw.jku.at> wrote:
>>
>>> Brad, if I understand your approach too that would lead to not being
>>> able to dynamically change common properties in a single config place
>>> during runtime, as the fill made by maven would be only done once at build
>>> time right? But at runtime I would need to that as David mention, still n
>>> times right?
>>>
>>> as a use case for instance, with blueprint:cm update-strategy configured
>>> as 'reload' in combination with felix-fileinstall as directory watcher,
>>> bundles are reloaded automatically so that when I modify at anytime during
>>> runtime a property e.g with just a text editor the bundle is initiated
>>> again with the new property values which is a quite nice feature
>>>
>>> best
>>>
>>> Pablo
>>>
>>> On 12/07/2016 12:31 AM, David Jencks wrote:
>>>
>>> I’d like to make sure I understand what you are doing here…. IIUC
>>> during the build of your project you are generating multiple configuration
>>> files with the same or similar content, and each of these is loaded into a
>>> configuration which is bound to a particular bundle location? So, at build
>>> time you can change all the duplicate properties at once but if you need to
>>> change them later you have to alter n (== number of duplicate configs)
>>> independently? Whereas if you had multi-location support (and possibly
>>> multi-pid support such as DS provides) you could share a single
>>> Configuration and change the property while the framework was running in
>>> one place?
>>>
>>> thanks
>>> david jencks
>>>
>>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <br...@mediadriver.com>
>>> wrote:
>>>
>>> Pablo,
>>>
>>> One possible solution to this problem that I'm currently looking at is
>>> using a configuration bundle along with my features bundle. In the
>>> configuration bundle I have all the cfg files and use properties
>>> placeholders ${value} to set the value for key/value.
>>>
>>> In the POM I load properties files using the Maven properties plugin and
>>> that lets me set a global set of properties values that can be used in
>>> filling in the cfg values. So if a port or URI is shared across a large
>>> number of them that automatically gets filled in. The features file can
>>> then specify the cfg files to install and what name to install them with.
>>>
>>> This gets rid of a lot of tedium and by using profiles I should be able
>>> to switch dev, test and production, and have the properties automatically
>>> set correctly.
>>>
>>> I'd like to modify this a bit so that dev, test and product cfg files
>>> are all created simultaneously and simply installed in different
>>> directories inside the configuration bundle. Then by using different
>>> features installs I can easily switch between the different configurations
>>> without having to tediously edit each configuration file.
>>>
>>> Brad
>>>
>>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> Does Camel/Fuse even support DS? I haven't found any documentation
>>>> saying otherwise. I've only found camel-scr which uses Felix-specific
>>>> annotations and not DS.
>>>>
>>>> On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com>
>>>> wrote:
>>>>
>>>>> David,
>>>>>
>>>>> That is some pretty extreme and wild speculation alright. How does
>>>>> one use blueprint to not use OSGi appropriately? In the 5 years I've been
>>>>> consulting with Fuse/Karaf/OSGi and going to various clients not one of
>>>>> them used or uses DS. Not one. They all use bundles, services, and Camel
>>>>> with blueprint. The last time I worked with DS I didn't find it provided
>>>>> any serious advantage and added another layer that I'd have to teach my
>>>>> clients. Not that I wouldn't consider it or use it if I found a real
>>>>> advantage but I haven't.
>>>>>
>>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi
>>>>> 4.x land much less 5 or 6.
>>>>>
>>>>> So for Camel are you using the Java DSL?
>>>>>
>>>>> Brad
>>>>>
>>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <da...@yahoo.com>
>>>>> wrote:
>>>>>
>>>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you look at
>>>>>> the osgi R5 or R6 config admin spec for “multi location”.
>>>>>>
>>>>>> You guys might be using blueprint every day, but there is no OSGI
>>>>>> spec work to keep it up to date or even specify obviously necessary
>>>>>> features such as config admin integration. If blueprint is so great why
>>>>>> aren’t the proponents keeping the spec related to current OSGI? This is a
>>>>>> part of my, admittedly extreme, theory that use of blueprint is related to
>>>>>> not wanting to make the app actually use osgi appropriately.
>>>>>>
>>>>>> And, the project I work on every day uses DS exclusively and still
>>>>>> finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>>>>
>>>>>> david jencks
>>>>>>
>>>>>>
>>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com> wrote:
>>>>>>
>>>>>> It is in here;
>>>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>>>>
>>>>>> A bundle is in aries bound to the pid. So it is actually working as
>>>>>> expected, bit of
>>>>>> a hassle since spring-dm allowed it.
>>>>>>
>>>>>> And yes selling DS into “regular" organizations is about as easy as
>>>>>> selling snow in Alaska.
>>>>>>
>>>>>> /je
>>>>>>
>>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <
>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>
>>>>>> David,
>>>>>>
>>>>>> You live in a very different world than I do. In all the consulting
>>>>>> I do with Fuse/karaf blueprint is used almost exclusively. I understand DS
>>>>>> and its uses but also its limits and overhead. It's like telling me one
>>>>>> should only use Camel Java DSL. That may be one's perspective but that
>>>>>> isn't everyone's.
>>>>>>
>>>>>> Brad
>>>>>>
>>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <david_jencks@yahoo.com
>>>>>> > wrote:
>>>>>>
>>>>>>> IMNSHO blueprint is only really plausible if you have a large amount
>>>>>>> of Spring based code and you need to convert it to be sort of
>>>>>>> osgi-compatible really quickly without understanding osgi or the code.
>>>>>>> Otherwise taking the time to understand DS and use it is much more
>>>>>>> satisfactory. DS provides this configuration override ability with support
>>>>>>> for multiple pids, although only one of the pids can turn out to be a
>>>>>>> factory configuration. There’s no obvious way of correlating factory
>>>>>>> configurations, so this restriction makes some sense.
>>>>>>>
>>>>>>> I don’t think there really are any blueprint folks. The cm stuff,
>>>>>>> while obviously required to make the spec remotely plausible, hasn’t made
>>>>>>> it into the spec in the many many years it’s been sitting around.
>>>>>>>
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <
>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>
>>>>>>> If I were to sit down with the blueprint folks today to create a
>>>>>>> wish list one thing I'd like to see is for an ability to have a
>>>>>>> configuration hierarchy specified with parent/child relationships much like
>>>>>>> one has in Maven. Have a base configuration file and be able to have
>>>>>>> another cfg file specify that one as its parent. Override properties or add
>>>>>>> them to the child. When the configuration admin fires up it would read up
>>>>>>> the chain and construct the properties.
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>
>>>>>>>> Ray,
>>>>>>>>
>>>>>>>> If I understand your question right the answer is the Aries
>>>>>>>> extension is referencing configuration. In karaf/fuse for example the
>>>>>>>> following:
>>>>>>>>
>>>>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>>>>> update-strategy="reload">
>>>>>>>>
>>>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>>>
>>>>>>>> Installing that file is done either manually or by use of a
>>>>>>>> features file.
>>>>>>>>
>>>>>>>> Whenever I've attempted to use the PID in more than one bundle it
>>>>>>>> has failed and I don't think it is permitted. That's a problem I think and
>>>>>>>> something that should be fixed through some other configuration management
>>>>>>>> mechanism. Making microservices that might share common properties, for
>>>>>>>> example, becomes problematic in that regard and I've resorted to using my
>>>>>>>> own OSGi services to overcome that problem.
>>>>>>>>
>>>>>>>> Brad
>>>>>>>>
>>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>
>>>>>>>>> Ok, so after a brief review the cm schema is an Aries extension
>>>>>>>>> and it doesn't appear to support the location binding.
>>>>>>>>>
>>>>>>>>> However, it's unclear to me whether this extension is creating the
>>>>>>>>> configuration or merely referencing one from outside.
>>>>>>>>>
>>>>>>>>> Any Aries gurus can answer that?
>>>>>>>>>
>>>>>>>>> - Ray
>>>>>>>>>
>>>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <
>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>>> I’m not really familiar with blueprint cm but I’d expect that to
>>>>>>>>>> indicate which pid to use to fetch the config from config admin and in the
>>>>>>>>>> ... how to map configuration propertiething blueprint substitution knows
>>>>>>>>>> about. Is that really instructions to create a new configuration and
>>>>>>>>>> populate it with data (what a management agent does)?
>>>>>>>>>>
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <
>>>>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>>>>
>>>>>>>>>> David, I agree with everything you've said, however this looks
>>>>>>>>>> like blueprint being the agent here:
>>>>>>>>>>
>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>> update-strategy="reload">
>>>>>>>>>> ...
>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>
>>>>>>>>>> - Ray
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> No, blueprint cm shouldn’t really know about the
>>>>>>>>>>> multi-location. The management agent that is creating the configuration
>>>>>>>>>>> should be setting the bundle location to the multi-location ”?”.
>>>>>>>>>>>
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I see and would it possible to configure which method is invoked
>>>>>>>>>>> from Blueprint?
>>>>>>>>>>>
>>>>>>>>>>> This is how I do it:
>>>>>>>>>>>
>>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>>> update-strategy="reload">
>>>>>>>>>>> ...
>>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>>
>>>>>>>>>>> is there perhaps some blueprint property where I can tune the
>>>>>>>>>>> second argument in the createFactoryConfiguration?
>>>>>>>>>>>
>>>>>>>>>>> Because it looks like the fact of using config admin through
>>>>>>>>>>> blueprint binds the PID to the first bundle using it
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> best
>>>>>>>>>>> Pablo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>>>
>>>>>>>>>>> As long as configurations are not bound to a bundle they can be
>>>>>>>>>>> used by any bundle.
>>>>>>>>>>>
>>>>>>>>>>> The exception clearly shows that the configuration is bound to a
>>>>>>>>>>> bundle.
>>>>>>>>>>>
>>>>>>>>>>> Creating an unbound configuration requires passing a "?" as the
>>>>>>>>>>> second arguments to getConfiguration/createFactoryConfiguration methods of
>>>>>>>>>>> CM.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> HTH,
>>>>>>>>>>> - Ray
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is it possible to use same config file from multiple
>>>>>>>>>>>>> bundles while using Config Admin with blueprint Blueprint? Because, I can't
>>>>>>>>>>>>> manage to do that, I get the following error:
>>>>>>>>>>>>>
>>>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No visibility
>>>>>>>>>>>>> to configuration bound to initial@reference:file:../plugin-2/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, I fear that this is a problem in the aries blueprint
>>>>>>>>>>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> As a workaround I can make a config file per bundle that needs
>>>>>>>>>>>>> it....
>>>>>>>>>>>>>
>>>>>>>>>>>>> As follows the versions and bundles that I'm using related to
>>>>>>>>>>>>> the container (Running on top of Equinox 3.11):
>>>>>>>>>>>>>
>>>>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for
>>>>>>>>>>>>> JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology
>>>>>>>>>>>>> Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>>> Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core
>>>>>>>>>>>>> (1.5.0)|1.5.0
>>>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core
>>>>>>>>>>>>> Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service
>>>>>>>>>>>>> Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>>> (1.1.1)|1.1.1
>>>>>>>>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy
>>>>>>>>>>>>> Runtimes (1.0.0)|1.0.0
>>>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>>> Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin provider
>>>>>>>>>>>>> TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>>> (2.1.0)|2.1.0
>>>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>>> Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>>> Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service
>>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving
>>>>>>>>>>>>> Bundle (1.0.8)|1.0.8
>>>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint
>>>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>>>>
>>>>>>>>>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command
>>>>>>>>>>>>> (0.16.0)|0.16.0
>>>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime
>>>>>>>>>>>>> (0.16.2)|0.16.2
>>>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>>>>>>>>>> (1.2.8)|1.2.8
>>>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin
>>>>>>>>>>>>> Service (1.8.8)|1.8.8
>>>>>>>>>>>>>
>>>>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email. The
>>>>>>>>>>>>> recipient should check this email and any attachments for the presence of
>>>>>>>>>>>>> viruses. The company accepts no liability for any damage caused by any
>>>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Warning: Although the company has taken reasonable precautions
>>>>>>>>>>>>> to ensure no viruses are present in this email, the company cannot accept
>>>>>>>>>>>>> responsibility for any loss or damage arising from the use of this email or
>>>>>>>>>>>>> attachments.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>> (@rotty3000)
>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>> (@rotty3000)
>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>>
>>
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
David,
I'm all for multilocation support in blueprint. Can't wait for it. But
it sounds like your saying blueprint is dead and nobody cares about it
anymore so it doesn't seem likely to happen anytime soon. It certainly
wouldn't be relevant to Fuse which uses R4 in any case.
On Tue, Jul 12, 2016 at 10:21 AM, Brad Johnson <brad.johnson@mediadriver.com
> wrote:
> The features file can have statements like this:
>
>
> <configfile finalname="/etc/com.foo.cfg"
> override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
> <configfile finalname="/etc/com.bar.cfg"
> override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
> ....etc....
> That's off the top of my head so take it with a grain of salt for syntax.
>
> When you run the features install it will overwrite the files in the etc
> directory with the ones in the maven bundle which have now been updated. So
> instead of modifying configuration files in the etc directory you modifying
> them in your Maven configuration project and recompile the bundle and then
> pull it from the repo
> in order to update the values.
>
> But you can still modify them in the etc if you wanted. You just have to
> make sure you have the cm properties set to reload.
>
> <cm:property-placeholder persistent-id="com.foo" update-strategy="reload">
>
> On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at
> > wrote:
>
>> Brad, if I understand your approach too that would lead to not being able
>> to dynamically change common properties in a single config place during
>> runtime, as the fill made by maven would be only done once at build time
>> right? But at runtime I would need to that as David mention, still n times
>> right?
>>
>> as a use case for instance, with blueprint:cm update-strategy configured
>> as 'reload' in combination with felix-fileinstall as directory watcher,
>> bundles are reloaded automatically so that when I modify at anytime during
>> runtime a property e.g with just a text editor the bundle is initiated
>> again with the new property values which is a quite nice feature
>>
>> best
>>
>> Pablo
>>
>> On 12/07/2016 12:31 AM, David Jencks wrote:
>>
>> I’d like to make sure I understand what you are doing here…. IIUC during
>> the build of your project you are generating multiple configuration files
>> with the same or similar content, and each of these is loaded into a
>> configuration which is bound to a particular bundle location? So, at build
>> time you can change all the duplicate properties at once but if you need to
>> change them later you have to alter n (== number of duplicate configs)
>> independently? Whereas if you had multi-location support (and possibly
>> multi-pid support such as DS provides) you could share a single
>> Configuration and change the property while the framework was running in
>> one place?
>>
>> thanks
>> david jencks
>>
>> On Jul 11, 2016, at 1:42 PM, Brad Johnson <br...@mediadriver.com>
>> wrote:
>>
>> Pablo,
>>
>> One possible solution to this problem that I'm currently looking at is
>> using a configuration bundle along with my features bundle. In the
>> configuration bundle I have all the cfg files and use properties
>> placeholders ${value} to set the value for key/value.
>>
>> In the POM I load properties files using the Maven properties plugin and
>> that lets me set a global set of properties values that can be used in
>> filling in the cfg values. So if a port or URI is shared across a large
>> number of them that automatically gets filled in. The features file can
>> then specify the cfg files to install and what name to install them with.
>>
>> This gets rid of a lot of tedium and by using profiles I should be able
>> to switch dev, test and production, and have the properties automatically
>> set correctly.
>>
>> I'd like to modify this a bit so that dev, test and product cfg files are
>> all created simultaneously and simply installed in different directories
>> inside the configuration bundle. Then by using different features installs
>> I can easily switch between the different configurations without having to
>> tediously edit each configuration file.
>>
>> Brad
>>
>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> Does Camel/Fuse even support DS? I haven't found any documentation
>>> saying otherwise. I've only found camel-scr which uses Felix-specific
>>> annotations and not DS.
>>>
>>> On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com>
>>> wrote:
>>>
>>>> David,
>>>>
>>>> That is some pretty extreme and wild speculation alright. How does one
>>>> use blueprint to not use OSGi appropriately? In the 5 years I've been
>>>> consulting with Fuse/Karaf/OSGi and going to various clients not one of
>>>> them used or uses DS. Not one. They all use bundles, services, and Camel
>>>> with blueprint. The last time I worked with DS I didn't find it provided
>>>> any serious advantage and added another layer that I'd have to teach my
>>>> clients. Not that I wouldn't consider it or use it if I found a real
>>>> advantage but I haven't.
>>>>
>>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi
>>>> 4.x land much less 5 or 6.
>>>>
>>>> So for Camel are you using the Java DSL?
>>>>
>>>> Brad
>>>>
>>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <da...@yahoo.com>
>>>> wrote:
>>>>
>>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you look at
>>>>> the osgi R5 or R6 config admin spec for “multi location”.
>>>>>
>>>>> You guys might be using blueprint every day, but there is no OSGI spec
>>>>> work to keep it up to date or even specify obviously necessary features
>>>>> such as config admin integration. If blueprint is so great why aren’t the
>>>>> proponents keeping the spec related to current OSGI? This is a part of my,
>>>>> admittedly extreme, theory that use of blueprint is related to not wanting
>>>>> to make the app actually use osgi appropriately.
>>>>>
>>>>> And, the project I work on every day uses DS exclusively and still
>>>>> finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>>>
>>>>> david jencks
>>>>>
>>>>>
>>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com> wrote:
>>>>>
>>>>> It is in here;
>>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>>>
>>>>> A bundle is in aries bound to the pid. So it is actually working as
>>>>> expected, bit of
>>>>> a hassle since spring-dm allowed it.
>>>>>
>>>>> And yes selling DS into “regular" organizations is about as easy as
>>>>> selling snow in Alaska.
>>>>>
>>>>> /je
>>>>>
>>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <
>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>
>>>>> David,
>>>>>
>>>>> You live in a very different world than I do. In all the consulting I
>>>>> do with Fuse/karaf blueprint is used almost exclusively. I understand DS
>>>>> and its uses but also its limits and overhead. It's like telling me one
>>>>> should only use Camel Java DSL. That may be one's perspective but that
>>>>> isn't everyone's.
>>>>>
>>>>> Brad
>>>>>
>>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <da...@yahoo.com>
>>>>> wrote:
>>>>>
>>>>>> IMNSHO blueprint is only really plausible if you have a large amount
>>>>>> of Spring based code and you need to convert it to be sort of
>>>>>> osgi-compatible really quickly without understanding osgi or the code.
>>>>>> Otherwise taking the time to understand DS and use it is much more
>>>>>> satisfactory. DS provides this configuration override ability with support
>>>>>> for multiple pids, although only one of the pids can turn out to be a
>>>>>> factory configuration. There’s no obvious way of correlating factory
>>>>>> configurations, so this restriction makes some sense.
>>>>>>
>>>>>> I don’t think there really are any blueprint folks. The cm stuff,
>>>>>> while obviously required to make the spec remotely plausible, hasn’t made
>>>>>> it into the spec in the many many years it’s been sitting around.
>>>>>>
>>>>>> david jencks
>>>>>>
>>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <
>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>
>>>>>> If I were to sit down with the blueprint folks today to create a wish
>>>>>> list one thing I'd like to see is for an ability to have a configuration
>>>>>> hierarchy specified with parent/child relationships much like one has in
>>>>>> Maven. Have a base configuration file and be able to have another cfg file
>>>>>> specify that one as its parent. Override properties or add them to the
>>>>>> child. When the configuration admin fires up it would read up the chain
>>>>>> and construct the properties.
>>>>>>
>>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>
>>>>>>> Ray,
>>>>>>>
>>>>>>> If I understand your question right the answer is the Aries
>>>>>>> extension is referencing configuration. In karaf/fuse for example the
>>>>>>> following:
>>>>>>>
>>>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>>>> update-strategy="reload">
>>>>>>>
>>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>>
>>>>>>> Installing that file is done either manually or by use of a features
>>>>>>> file.
>>>>>>>
>>>>>>> Whenever I've attempted to use the PID in more than one bundle it
>>>>>>> has failed and I don't think it is permitted. That's a problem I think and
>>>>>>> something that should be fixed through some other configuration management
>>>>>>> mechanism. Making microservices that might share common properties, for
>>>>>>> example, becomes problematic in that regard and I've resorted to using my
>>>>>>> own OSGi services to overcome that problem.
>>>>>>>
>>>>>>> Brad
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>>
>>>>>>>> Ok, so after a brief review the cm schema is an Aries extension and
>>>>>>>> it doesn't appear to support the location binding.
>>>>>>>>
>>>>>>>> However, it's unclear to me whether this extension is creating the
>>>>>>>> configuration or merely referencing one from outside.
>>>>>>>>
>>>>>>>> Any Aries gurus can answer that?
>>>>>>>>
>>>>>>>> - Ray
>>>>>>>>
>>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <
>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>
>>>>>>>>> I’m not really familiar with blueprint cm but I’d expect that to
>>>>>>>>> indicate which pid to use to fetch the config from config admin and in the
>>>>>>>>> ... how to map configuration propertiething blueprint substitution knows
>>>>>>>>> about. Is that really instructions to create a new configuration and
>>>>>>>>> populate it with data (what a management agent does)?
>>>>>>>>>
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> David, I agree with everything you've said, however this looks
>>>>>>>>> like blueprint being the agent here:
>>>>>>>>>
>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>> update-strategy="reload">
>>>>>>>>> ...
>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>
>>>>>>>>> - Ray
>>>>>>>>>
>>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>>> No, blueprint cm shouldn’t really know about the multi-location.
>>>>>>>>>> The management agent that is creating the configuration should be setting
>>>>>>>>>> the bundle location to the multi-location ”?”.
>>>>>>>>>>
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>
>>>>>>>>>> I see and would it possible to configure which method is invoked
>>>>>>>>>> from Blueprint?
>>>>>>>>>>
>>>>>>>>>> This is how I do it:
>>>>>>>>>>
>>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>>> update-strategy="reload">
>>>>>>>>>> ...
>>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>>
>>>>>>>>>> is there perhaps some blueprint property where I can tune the
>>>>>>>>>> second argument in the createFactoryConfiguration?
>>>>>>>>>>
>>>>>>>>>> Because it looks like the fact of using config admin through
>>>>>>>>>> blueprint binds the PID to the first bundle using it
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> best
>>>>>>>>>> Pablo
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>>
>>>>>>>>>> As long as configurations are not bound to a bundle they can be
>>>>>>>>>> used by any bundle.
>>>>>>>>>>
>>>>>>>>>> The exception clearly shows that the configuration is bound to a
>>>>>>>>>> bundle.
>>>>>>>>>>
>>>>>>>>>> Creating an unbound configuration requires passing a "?" as the
>>>>>>>>>> second arguments to getConfiguration/createFactoryConfiguration methods of
>>>>>>>>>> CM.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> HTH,
>>>>>>>>>> - Ray
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello All,
>>>>>>>>>>>>
>>>>>>>>>>>> Is it possible to use same config file from multiple
>>>>>>>>>>>> bundles while using Config Admin with blueprint Blueprint? Because, I can't
>>>>>>>>>>>> manage to do that, I get the following error:
>>>>>>>>>>>>
>>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No visibility
>>>>>>>>>>>> to configuration bound to initial@reference:file:../plugin-2/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> However, I fear that this is a problem in the aries blueprint
>>>>>>>>>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> As a workaround I can make a config file per bundle that needs
>>>>>>>>>>>> it....
>>>>>>>>>>>>
>>>>>>>>>>>> As follows the versions and bundles that I'm using related to
>>>>>>>>>>>> the container (Running on top of Equinox 3.11):
>>>>>>>>>>>>
>>>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>>>>>>>>>>> DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology
>>>>>>>>>>>> Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>> Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core
>>>>>>>>>>>> (1.5.0)|1.5.0
>>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core
>>>>>>>>>>>> Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service
>>>>>>>>>>>> Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>> (1.1.1)|1.1.1
>>>>>>>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy
>>>>>>>>>>>> Runtimes (1.0.0)|1.0.0
>>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>> Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>>> (2.1.0)|2.1.0
>>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>> Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>>> Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving
>>>>>>>>>>>> Bundle (1.0.8)|1.0.8
>>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint
>>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>>>
>>>>>>>>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command
>>>>>>>>>>>> (0.16.0)|0.16.0
>>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime
>>>>>>>>>>>> (0.16.2)|0.16.2
>>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>>>>>>>>> (1.2.8)|1.2.8
>>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin
>>>>>>>>>>>> Service (1.8.8)|1.8.8
>>>>>>>>>>>>
>>>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email. The
>>>>>>>>>>>> recipient should check this email and any attachments for the presence of
>>>>>>>>>>>> viruses. The company accepts no liability for any damage caused by any
>>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>>>
>>>>>>>>>>>> Warning: Although the company has taken reasonable precautions
>>>>>>>>>>>> to ensure no viruses are present in this email, the company cannot accept
>>>>>>>>>>>> responsibility for any loss or damage arising from the use of this email or
>>>>>>>>>>>> attachments.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>> (@rotty3000)
>>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>> (@rotty3000)
>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>> (@rotty3000)
>>>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>>>>>> (@Liferay)
>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>> (@OSGiAlliance)
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
The features file can have statements like this:
<configfile finalname="/etc/com.foo.cfg"
override="true">mvn:com.confignuration/myrpoject/${project.version}/cfg/com.foo</configfile>
<configfile finalname="/etc/com.bar.cfg"
override="true">mvn:comconfiguration/myproect/${project.version}/cfg/com.bar</configfile>
....etc....
That's off the top of my head so take it with a grain of salt for syntax.
When you run the features install it will overwrite the files in the etc
directory with the ones in the maven bundle which have now been updated. So
instead of modifying configuration files in the etc directory you modifying
them in your Maven configuration project and recompile the bundle and then
pull it from the repo
in order to update the values.
But you can still modify them in the etc if you wanted. You just have to
make sure you have the cm properties set to reload.
<cm:property-placeholder persistent-id="com.foo" update-strategy="reload">
On Tue, Jul 12, 2016 at 9:45 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
wrote:
> Brad, if I understand your approach too that would lead to not being able
> to dynamically change common properties in a single config place during
> runtime, as the fill made by maven would be only done once at build time
> right? But at runtime I would need to that as David mention, still n times
> right?
>
> as a use case for instance, with blueprint:cm update-strategy configured
> as 'reload' in combination with felix-fileinstall as directory watcher,
> bundles are reloaded automatically so that when I modify at anytime during
> runtime a property e.g with just a text editor the bundle is initiated
> again with the new property values which is a quite nice feature
>
> best
>
> Pablo
>
> On 12/07/2016 12:31 AM, David Jencks wrote:
>
> I’d like to make sure I understand what you are doing here…. IIUC during
> the build of your project you are generating multiple configuration files
> with the same or similar content, and each of these is loaded into a
> configuration which is bound to a particular bundle location? So, at build
> time you can change all the duplicate properties at once but if you need to
> change them later you have to alter n (== number of duplicate configs)
> independently? Whereas if you had multi-location support (and possibly
> multi-pid support such as DS provides) you could share a single
> Configuration and change the property while the framework was running in
> one place?
>
> thanks
> david jencks
>
> On Jul 11, 2016, at 1:42 PM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
> Pablo,
>
> One possible solution to this problem that I'm currently looking at is
> using a configuration bundle along with my features bundle. In the
> configuration bundle I have all the cfg files and use properties
> placeholders ${value} to set the value for key/value.
>
> In the POM I load properties files using the Maven properties plugin and
> that lets me set a global set of properties values that can be used in
> filling in the cfg values. So if a port or URI is shared across a large
> number of them that automatically gets filled in. The features file can
> then specify the cfg files to install and what name to install them with.
>
> This gets rid of a lot of tedium and by using profiles I should be able to
> switch dev, test and production, and have the properties automatically set
> correctly.
>
> I'd like to modify this a bit so that dev, test and product cfg files are
> all created simultaneously and simply installed in different directories
> inside the configuration bundle. Then by using different features installs
> I can easily switch between the different configurations without having to
> tediously edit each configuration file.
>
> Brad
>
> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com> wrote:
>
>> Does Camel/Fuse even support DS? I haven't found any documentation saying
>> otherwise. I've only found camel-scr which uses Felix-specific annotations
>> and not DS.
>>
>> On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com>
>> wrote:
>>
>>> David,
>>>
>>> That is some pretty extreme and wild speculation alright. How does one
>>> use blueprint to not use OSGi appropriately? In the 5 years I've been
>>> consulting with Fuse/Karaf/OSGi and going to various clients not one of
>>> them used or uses DS. Not one. They all use bundles, services, and Camel
>>> with blueprint. The last time I worked with DS I didn't find it provided
>>> any serious advantage and added another layer that I'd have to teach my
>>> clients. Not that I wouldn't consider it or use it if I found a real
>>> advantage but I haven't.
>>>
>>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi 4.x
>>> land much less 5 or 6.
>>>
>>> So for Camel are you using the Java DSL?
>>>
>>> Brad
>>>
>>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <da...@yahoo.com>
>>> wrote:
>>>
>>>> I don’t think karaf is at osgi R4.2 any more, I suggest you look at the
>>>> osgi R5 or R6 config admin spec for “multi location”.
>>>>
>>>> You guys might be using blueprint every day, but there is no OSGI spec
>>>> work to keep it up to date or even specify obviously necessary features
>>>> such as config admin integration. If blueprint is so great why aren’t the
>>>> proponents keeping the spec related to current OSGI? This is a part of my,
>>>> admittedly extreme, theory that use of blueprint is related to not wanting
>>>> to make the app actually use osgi appropriately.
>>>>
>>>> And, the project I work on every day uses DS exclusively and still
>>>> finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>>
>>>> david jencks
>>>>
>>>>
>>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com> wrote:
>>>>
>>>> It is in here;
>>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>>
>>>> A bundle is in aries bound to the pid. So it is actually working as
>>>> expected, bit of
>>>> a hassle since spring-dm allowed it.
>>>>
>>>> And yes selling DS into “regular" organizations is about as easy as
>>>> selling snow in Alaska.
>>>>
>>>> /je
>>>>
>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <br...@mediadriver.com>
>>>> wrote:
>>>>
>>>> David,
>>>>
>>>> You live in a very different world than I do. In all the consulting I
>>>> do with Fuse/karaf blueprint is used almost exclusively. I understand DS
>>>> and its uses but also its limits and overhead. It's like telling me one
>>>> should only use Camel Java DSL. That may be one's perspective but that
>>>> isn't everyone's.
>>>>
>>>> Brad
>>>>
>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <da...@yahoo.com>
>>>> wrote:
>>>>
>>>>> IMNSHO blueprint is only really plausible if you have a large amount
>>>>> of Spring based code and you need to convert it to be sort of
>>>>> osgi-compatible really quickly without understanding osgi or the code.
>>>>> Otherwise taking the time to understand DS and use it is much more
>>>>> satisfactory. DS provides this configuration override ability with support
>>>>> for multiple pids, although only one of the pids can turn out to be a
>>>>> factory configuration. There’s no obvious way of correlating factory
>>>>> configurations, so this restriction makes some sense.
>>>>>
>>>>> I don’t think there really are any blueprint folks. The cm stuff,
>>>>> while obviously required to make the spec remotely plausible, hasn’t made
>>>>> it into the spec in the many many years it’s been sitting around.
>>>>>
>>>>> david jencks
>>>>>
>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <
>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>
>>>>> If I were to sit down with the blueprint folks today to create a wish
>>>>> list one thing I'd like to see is for an ability to have a configuration
>>>>> hierarchy specified with parent/child relationships much like one has in
>>>>> Maven. Have a base configuration file and be able to have another cfg file
>>>>> specify that one as its parent. Override properties or add them to the
>>>>> child. When the configuration admin fires up it would read up the chain
>>>>> and construct the properties.
>>>>>
>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>
>>>>>> Ray,
>>>>>>
>>>>>> If I understand your question right the answer is the Aries extension
>>>>>> is referencing configuration. In karaf/fuse for example the following:
>>>>>>
>>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>>> update-strategy="reload">
>>>>>>
>>>>>> will load properties from etc/com.my.foo.cfg
>>>>>>
>>>>>> Installing that file is done either manually or by use of a features
>>>>>> file.
>>>>>>
>>>>>> Whenever I've attempted to use the PID in more than one bundle it has
>>>>>> failed and I don't think it is permitted. That's a problem I think and
>>>>>> something that should be fixed through some other configuration management
>>>>>> mechanism. Making microservices that might share common properties, for
>>>>>> example, becomes problematic in that regard and I've resorted to using my
>>>>>> own OSGi services to overcome that problem.
>>>>>>
>>>>>> Brad
>>>>>>
>>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>>> raymond.auge@liferay.com> wrote:
>>>>>>
>>>>>>> Ok, so after a brief review the cm schema is an Aries extension and
>>>>>>> it doesn't appear to support the location binding.
>>>>>>>
>>>>>>> However, it's unclear to me whether this extension is creating the
>>>>>>> configuration or merely referencing one from outside.
>>>>>>>
>>>>>>> Any Aries gurus can answer that?
>>>>>>>
>>>>>>> - Ray
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <
>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>
>>>>>>>> I’m not really familiar with blueprint cm but I’d expect that to
>>>>>>>> indicate which pid to use to fetch the config from config admin and in the
>>>>>>>> ... how to map configuration propertiething blueprint substitution knows
>>>>>>>> about. Is that really instructions to create a new configuration and
>>>>>>>> populate it with data (what a management agent does)?
>>>>>>>>
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> David, I agree with everything you've said, however this looks like
>>>>>>>> blueprint being the agent here:
>>>>>>>>
>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>> update-strategy="reload">
>>>>>>>> ...
>>>>>>>> </cm:property-placeholder>
>>>>>>>>
>>>>>>>> - Ray
>>>>>>>>
>>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>>
>>>>>>>>> No, blueprint cm shouldn’t really know about the multi-location.
>>>>>>>>> The management agent that is creating the configuration should be setting
>>>>>>>>> the bundle location to the multi-location ”?”.
>>>>>>>>>
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>
>>>>>>>>> I see and would it possible to configure which method is invoked
>>>>>>>>> from Blueprint?
>>>>>>>>>
>>>>>>>>> This is how I do it:
>>>>>>>>>
>>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>>> update-strategy="reload">
>>>>>>>>> ...
>>>>>>>>> </cm:property-placeholder>
>>>>>>>>>
>>>>>>>>> is there perhaps some blueprint property where I can tune the
>>>>>>>>> second argument in the createFactoryConfiguration?
>>>>>>>>>
>>>>>>>>> Because it looks like the fact of using config admin through
>>>>>>>>> blueprint binds the PID to the first bundle using it
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> best
>>>>>>>>> Pablo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>>
>>>>>>>>> As long as configurations are not bound to a bundle they can be
>>>>>>>>> used by any bundle.
>>>>>>>>>
>>>>>>>>> The exception clearly shows that the configuration is bound to a
>>>>>>>>> bundle.
>>>>>>>>>
>>>>>>>>> Creating an unbound configuration requires passing a "?" as the
>>>>>>>>> second arguments to getConfiguration/createFactoryConfiguration methods of
>>>>>>>>> CM.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> HTH,
>>>>>>>>> - Ray
>>>>>>>>>
>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>>
>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello All,
>>>>>>>>>>>
>>>>>>>>>>> Is it possible to use same config file from multiple
>>>>>>>>>>> bundles while using Config Admin with blueprint Blueprint? Because, I can't
>>>>>>>>>>> manage to do that, I get the following error:
>>>>>>>>>>>
>>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No visibility
>>>>>>>>>>> to configuration bound to initial@reference:file:../plugin-2/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> However, I fear that this is a problem in the aries blueprint
>>>>>>>>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> As a workaround I can make a config file per bundle that needs
>>>>>>>>>>> it....
>>>>>>>>>>>
>>>>>>>>>>> As follows the versions and bundles that I'm using related to
>>>>>>>>>>> the container (Running on top of Equinox 3.11):
>>>>>>>>>>>
>>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>>>>>>>>>> DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology
>>>>>>>>>>> Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>> Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
>>>>>>>>>>> Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service
>>>>>>>>>>> Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>> (1.1.1)|1.1.1
>>>>>>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy
>>>>>>>>>>> Runtimes (1.0.0)|1.0.0
>>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>> Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>>> (2.1.0)|2.1.0
>>>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>> Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>>> Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving
>>>>>>>>>>> Bundle (1.0.8)|1.0.8
>>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint
>>>>>>>>>>> integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>>
>>>>>>>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>>>>>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>>>>>>>> (1.2.8)|1.2.8
>>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin Service
>>>>>>>>>>> (1.8.8)|1.8.8
>>>>>>>>>>>
>>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> WARNING: Computer viruses can be transmitted via email. The
>>>>>>>>>>> recipient should check this email and any attachments for the presence of
>>>>>>>>>>> viruses. The company accepts no liability for any damage caused by any
>>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>>
>>>>>>>>>>> Warning: Although the company has taken reasonable precautions
>>>>>>>>>>> to ensure no viruses are present in this email, the company cannot accept
>>>>>>>>>>> responsibility for any loss or damage arising from the use of this email or
>>>>>>>>>>> attachments.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>> (@rotty3000)
>>>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>>> (@OSGiAlliance)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>> (@rotty3000)
>>>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>>>>>> (@Liferay)
>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>> (@OSGiAlliance)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>> (@rotty3000)
>>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>>>>> (@Liferay)
>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>> (@OSGiAlliance)
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Pablo Gómez Pérez <pa...@faw.jku.at>.
Brad, if I understand your approach too that would lead to not being
able to dynamically change common properties in a single config place
during runtime, as the fill made by maven would be only done once at
build time right? But at runtime I would need to that as David mention,
still n times right?
as a use case for instance, with blueprint:cm update-strategy configured
as 'reload' in combination with felix-fileinstall as directory watcher,
bundles are reloaded automatically so that when I modify at anytime
during runtime a property e.g with just a text editor the bundle is
initiated again with the new property values which is a quite nice feature
best
Pablo
On 12/07/2016 12:31 AM, David Jencks wrote:
> I\u2019d like to make sure I understand what you are doing here\u2026. IIUC
> during the build of your project you are generating multiple
> configuration files with the same or similar content, and each of
> these is loaded into a configuration which is bound to a particular
> bundle location? So, at build time you can change all the duplicate
> properties at once but if you need to change them later you have to
> alter n (== number of duplicate configs) independently? Whereas if
> you had multi-location support (and possibly multi-pid support such as
> DS provides) you could share a single Configuration and change the
> property while the framework was running in one place?
>
> thanks
> david jencks
>
>> On Jul 11, 2016, at 1:42 PM, Brad Johnson
>> <brad.johnson@mediadriver.com <ma...@mediadriver.com>>
>> wrote:
>>
>> Pablo,
>>
>> One possible solution to this problem that I'm currently looking at
>> is using a configuration bundle along with my features bundle. In
>> the configuration bundle I have all the cfg files and use properties
>> placeholders ${value} to set the value for key/value.
>>
>> In the POM I load properties files using the Maven properties plugin
>> and that lets me set a global set of properties values that can be
>> used in filling in the cfg values. So if a port or URI is shared
>> across a large number of them that automatically gets filled in. The
>> features file can then specify the cfg files to install and what name
>> to install them with.
>>
>> This gets rid of a lot of tedium and by using profiles I should be
>> able to switch dev, test and production, and have the properties
>> automatically set correctly.
>>
>> I'd like to modify this a bit so that dev, test and product cfg files
>> are all created simultaneously and simply installed in different
>> directories inside the configuration bundle. Then by using different
>> features installs I can easily switch between the different
>> configurations without having to tediously edit each configuration file.
>>
>> Brad
>>
>> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <boards@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> Does Camel/Fuse even support DS? I haven't found any
>> documentation saying otherwise. I've only found camel-scr which
>> uses Felix-specific annotations and not DS.
>>
>> On 7 July 2016 at 14:32, Brad Johnson
>> <brad.johnson@mediadriver.com
>> <ma...@mediadriver.com>> wrote:
>>
>> David,
>>
>> That is some pretty extreme and wild speculation alright. How
>> does one use blueprint to not use OSGi appropriately? In the
>> 5 years I've been consulting with Fuse/Karaf/OSGi and going
>> to various clients not one of them used or uses DS. Not
>> one. They all use bundles, services, and Camel with
>> blueprint. The last time I worked with DS I didn't find it
>> provided any serious advantage and added another layer that
>> I'd have to teach my clients. Not that I wouldn't consider
>> it or use it if I found a real advantage but I haven't.
>>
>> Red Hat is still shipping Karaf 2.x with Fuse so it is still
>> in OSGi 4.x land much less 5 or 6.
>>
>> So for Camel are you using the Java DSL?
>>
>> Brad
>>
>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks
>> <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>>
>> I don\u2019t think karaf is at osgi R4.2 any more, I suggest
>> you look at the osgi R5 or R6 config admin spec for
>> \u201cmulti location\u201d.
>>
>> You guys might be using blueprint every day, but there is
>> no OSGI spec work to keep it up to date or even specify
>> obviously necessary features such as config admin
>> integration. If blueprint is so great why aren\u2019t the
>> proponents keeping the spec related to current OSGI? This
>> is a part of my, admittedly extreme, theory that use of
>> blueprint is related to not wanting to make the app
>> actually use osgi appropriately.
>>
>> And, the project I work on every day uses DS exclusively
>> and still finds plenty of ways to abuse osgi in all sorts
>> of inventive ways :-)
>>
>> david jencks
>>
>>
>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom
>>> <seijoed@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> It is in here;
>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>
>>>
>>> A bundle is in aries bound to the pid. So it is actually
>>> working as expected, bit of
>>> a hassle since spring-dm allowed it.
>>>
>>> And yes selling DS into \u201cregular" organizations is about
>>> as easy as selling snow in Alaska.
>>>
>>> /je
>>>
>>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson
>>>> <brad.johnson@mediadriver.com
>>>> <ma...@mediadriver.com>> wrote:
>>>>
>>>> David,
>>>>
>>>> You live in a very different world than I do. In all
>>>> the consulting I do with Fuse/karaf blueprint is used
>>>> almost exclusively. I understand DS and its uses but
>>>> also its limits and overhead. It's like telling me one
>>>> should only use Camel Java DSL. That may be one's
>>>> perspective but that isn't everyone's.
>>>>
>>>> Brad
>>>>
>>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks
>>>> <david_jencks@yahoo.com
>>>> <ma...@yahoo.com>> wrote:
>>>>
>>>> IMNSHO blueprint is only really plausible if you
>>>> have a large amount of Spring based code and you
>>>> need to convert it to be sort of osgi-compatible
>>>> really quickly without understanding osgi or the
>>>> code. Otherwise taking the time to understand DS
>>>> and use it is much more satisfactory. DS provides
>>>> this configuration override ability with support
>>>> for multiple pids, although only one of the pids
>>>> can turn out to be a factory configuration.
>>>> There\u2019s no obvious way of correlating factory
>>>> configurations, so this restriction makes some sense.
>>>>
>>>> I don\u2019t think there really are any blueprint
>>>> folks. The cm stuff, while obviously required to
>>>> make the spec remotely plausible, hasn\u2019t made it
>>>> into the spec in the many many years it\u2019s been
>>>> sitting around.
>>>>
>>>> david jencks
>>>>
>>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson
>>>>> <brad.johnson@mediadriver.com
>>>>> <ma...@mediadriver.com>> wrote:
>>>>>
>>>>> If I were to sit down with the blueprint folks
>>>>> today to create a wish list one thing I'd like to
>>>>> see is for an ability to have a configuration
>>>>> hierarchy specified with parent/child
>>>>> relationships much like one has in Maven. Have a
>>>>> base configuration file and be able to have
>>>>> another cfg file specify that one as its parent.
>>>>> Override properties or add them to the child. When
>>>>> the configuration admin fires up it would read up
>>>>> the chain and construct the properties.
>>>>>
>>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson
>>>>> <brad.johnson@mediadriver.com
>>>>> <ma...@mediadriver.com>> wrote:
>>>>>
>>>>> Ray,
>>>>>
>>>>> If I understand your question right the answer
>>>>> is the Aries extension is referencing
>>>>> configuration. In karaf/fuse for example the
>>>>> following:
>>>>>
>>>>> <cm:property-placeholder
>>>>> persistent-id="com.my.foo"
>>>>> update-strategy="reload">
>>>>>
>>>>> will load properties from etc/com.my.foo.cfg
>>>>>
>>>>> Installing that file is done either manually
>>>>> or by use of a features file.
>>>>>
>>>>> Whenever I've attempted to use the PID in more
>>>>> than one bundle it has failed and I don't
>>>>> think it is permitted. That's a problem I
>>>>> think and something that should be fixed
>>>>> through some other configuration management
>>>>> mechanism. Making microservices that might
>>>>> share common properties, for example, becomes
>>>>> problematic in that regard and I've resorted
>>>>> to using my own OSGi services to overcome that
>>>>> problem.
>>>>>
>>>>> Brad
>>>>>
>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge
>>>>> <raymond.auge@liferay.com
>>>>> <ma...@liferay.com>> wrote:
>>>>>
>>>>> Ok, so after a brief review the cm schema
>>>>> is an Aries extension and it doesn't
>>>>> appear to support the location binding.
>>>>>
>>>>> However, it's unclear to me whether this
>>>>> extension is creating the configuration or
>>>>> merely referencing one from outside.
>>>>>
>>>>> Any Aries gurus can answer that?
>>>>>
>>>>> - Ray
>>>>>
>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David
>>>>> Jencks <david_jencks@yahoo.com
>>>>> <ma...@yahoo.com>> wrote:
>>>>>
>>>>> I\u2019m not really familiar with blueprint
>>>>> cm but I\u2019d expect that to indicate
>>>>> which pid to use to fetch the config
>>>>> from config admin and in the ... how
>>>>> to map configuration propertiething
>>>>> blueprint substitution knows about. Is
>>>>> that really instructions to create a
>>>>> new configuration and populate it with
>>>>> data (what a management agent does)?
>>>>>
>>>>> david jencks
>>>>>
>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond
>>>>>> Auge <raymond.auge@liferay.com
>>>>>> <ma...@liferay.com>> wrote:
>>>>>>
>>>>>> David, I agree with everything you've
>>>>>> said, however this looks like
>>>>>> blueprint being the agent here:
>>>>>>
>>>>>> <cm:property-placeholder
>>>>>> persistent-id="my.id <http://my.id/>"
>>>>>> update-strategy="reload">
>>>>>> ...
>>>>>> </cm:property-placeholder>
>>>>>>
>>>>>> - Ray
>>>>>>
>>>>>> On Thu, Jul 7, 2016 at 11:18 AM,
>>>>>> David Jencks <david_jencks@yahoo.com
>>>>>> <ma...@yahoo.com>> wrote:
>>>>>>
>>>>>> No, blueprint cm shouldn\u2019t really
>>>>>> know about the multi-location.
>>>>>> The management agent that is
>>>>>> creating the configuration should
>>>>>> be setting the bundle location to
>>>>>> the multi-location \u201d?\u201d.
>>>>>>
>>>>>> david jencks
>>>>>>
>>>>>>> On Jul 7, 2016, at 8:12 AM,
>>>>>>> Pablo G�mez P�rez
>>>>>>> <pablo.gomez@faw.jku.at
>>>>>>> <ma...@faw.jku.at>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I see and would it possible to
>>>>>>> configure which method is
>>>>>>> invoked from Blueprint?
>>>>>>>
>>>>>>> This is how I do it:
>>>>>>>
>>>>>>> <cm:property-placeholder
>>>>>>> persistent-id="my.id
>>>>>>> <http://my.id/>"
>>>>>>> update-strategy="reload">
>>>>>>> ...
>>>>>>> </cm:property-placeholder>
>>>>>>>
>>>>>>> is there perhaps some blueprint
>>>>>>> property where I can tune the
>>>>>>> second argument in the
>>>>>>> createFactoryConfiguration?
>>>>>>>
>>>>>>> Because it looks like the fact
>>>>>>> of using config admin through
>>>>>>> blueprint binds the PID to the
>>>>>>> first bundle using it
>>>>>>>
>>>>>>>
>>>>>>> best
>>>>>>> Pablo
>>>>>>>
>>>>>>>
>>>>>>> On 07/07/2016 4:41 PM, Raymond
>>>>>>> Auge wrote:
>>>>>>>> As long as configurations are
>>>>>>>> not bound to a bundle they can
>>>>>>>> be used by any bundle.
>>>>>>>>
>>>>>>>> The exception clearly shows
>>>>>>>> that the configuration is bound
>>>>>>>> to a bundle.
>>>>>>>>
>>>>>>>> Creating an unbound
>>>>>>>> configuration requires passing
>>>>>>>> a "?" as the second arguments
>>>>>>>> to
>>>>>>>> getConfiguration/createFactoryConfiguration
>>>>>>>> methods of CM.
>>>>>>>>
>>>>>>>>
>>>>>>>> HTH,
>>>>>>>> - Ray
>>>>>>>>
>>>>>>>> On Thu, Jul 7, 2016 at 10:24
>>>>>>>> AM, Brad Johnson
>>>>>>>> <brad.johnson@mediadriver.com
>>>>>>>> <ma...@mediadriver.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I don't think that's possible.
>>>>>>>>
>>>>>>>> On Thu, Jul 7, 2016 at 8:51
>>>>>>>> AM, Pablo G�mez P�rez
>>>>>>>> <pablo.gomez@faw.jku.at
>>>>>>>> <ma...@faw.jku.at>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hello All,
>>>>>>>>
>>>>>>>> Is it
>>>>>>>> possible to use same
>>>>>>>> config file from
>>>>>>>> multiple bundles while
>>>>>>>> using Config Admin with
>>>>>>>> blueprint Blueprint?
>>>>>>>> Because, I can't manage
>>>>>>>> to do that, I get the
>>>>>>>> following error:
>>>>>>>>
>>>>>>>> MESSAGE Cannot use
>>>>>>>> configuration
>>>>>>>> test.mybundle for
>>>>>>>> [org.osgi.service.cm
>>>>>>>> <http://org.osgi.service.cm/>.ManagedService,
>>>>>>>> id=214,
>>>>>>>> bundle=86/initial@reference:file:../plugin-1/
>>>>>>>> <mailto:bundle=86/initial@reference:file:../plugin-1/>]:
>>>>>>>> No visibility to
>>>>>>>> configuration bound to
>>>>>>>> initial@reference:file:../plugin-2/
>>>>>>>> <mailto:initial@reference:file:../plugin-2/>
>>>>>>>>
>>>>>>>>
>>>>>>>> I saw in this jira a
>>>>>>>> bug opened:
>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>
>>>>>>>>
>>>>>>>> However, I fear that
>>>>>>>> this is a problem in
>>>>>>>> the aries blueprint
>>>>>>>> implementation as I'm
>>>>>>>> not using KARAF nor
>>>>>>>> FUSE, just a plain osgi
>>>>>>>> container. Either that
>>>>>>>> or I'm missing some
>>>>>>>> blueprint
>>>>>>>> configuration. I'm
>>>>>>>> basically using
>>>>>>>> blueprint:cm
>>>>>>>>
>>>>>>>>
>>>>>>>> As a workaround I can
>>>>>>>> make a config file per
>>>>>>>> bundle that needs it....
>>>>>>>>
>>>>>>>> As follows the versions
>>>>>>>> and bundles that I'm
>>>>>>>> using related to the
>>>>>>>> container (Running on
>>>>>>>> top of Equinox 3.11):
>>>>>>>>
>>>>>>>> ID|State |Level|Name
>>>>>>>> 5|Active |
>>>>>>>> 2|Apache Aries
>>>>>>>> Whiteboard support for
>>>>>>>> JMX DynamicMBean
>>>>>>>> services (1.1.5)|1.1.5
>>>>>>>> 6|Active |
>>>>>>>> 2|Apache Aries JNDI
>>>>>>>> Core (1.0.2)|1.0.2
>>>>>>>> 13|Active |
>>>>>>>> 3|Aries Remote Service
>>>>>>>> Admin Topology Manager
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 15|Active |
>>>>>>>> 2|Aries JPA Container
>>>>>>>> (1.0.2)|1.0.2
>>>>>>>> 21|Active |
>>>>>>>> 2|Apache Aries JNDI API
>>>>>>>> (1.1.0)|1.1.0
>>>>>>>> 25|Active |
>>>>>>>> 3|Aries Remote Service
>>>>>>>> Admin Discovery Gogo
>>>>>>>> Commands
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 27|Active |
>>>>>>>> 2|Apache Aries
>>>>>>>> Blueprint CM (1.0.7)|1.0.7
>>>>>>>> 29|Active |
>>>>>>>> 2|Apache Aries JMX
>>>>>>>> Blueprint Core
>>>>>>>> (1.1.5)|1.1.5
>>>>>>>> 37|Active |
>>>>>>>> 2|Apache Aries JNDI URL
>>>>>>>> Handler (1.1.0)|1.1.0
>>>>>>>> 42|Active |
>>>>>>>> 2|Apache Aries JMX Core
>>>>>>>> (1.1.5)|1.1.5
>>>>>>>> 46|Active |
>>>>>>>> 2|Apache Aries
>>>>>>>> Blueprint Core
>>>>>>>> (1.5.0)|1.5.0
>>>>>>>> 47|Resolved |
>>>>>>>> 4|Apache Aries
>>>>>>>> Blueprint Core
>>>>>>>> Compatiblity Fragment
>>>>>>>> Bundle (1.0.0)|1.0.0
>>>>>>>> 55|Active |
>>>>>>>> 2|Apache Aries Util
>>>>>>>> (1.1.1)|1.1.1
>>>>>>>> 56|Active |
>>>>>>>> 2|Aries JPA Container
>>>>>>>> Managed Contexts
>>>>>>>> (1.0.4)|1.0.4
>>>>>>>> 59|Active |
>>>>>>>> 2|Apache Aries Proxy
>>>>>>>> API (1.0.1)|1.0.1
>>>>>>>> 67|Active |
>>>>>>>> 3|Aries Remote Service
>>>>>>>> Admin Service Provider
>>>>>>>> Interface
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 71|Active |
>>>>>>>> 2|Apache Aries
>>>>>>>> Transaction Blueprint
>>>>>>>> (1.1.1)|1.1.1
>>>>>>>> 73|Active |
>>>>>>>> 2|Aries JPA Container
>>>>>>>> API (1.0.2)|1.0.2
>>>>>>>> 77|Active |
>>>>>>>> 2|Apache Aries JNDI
>>>>>>>> Support for Legacy
>>>>>>>> Runtimes (1.0.0)|1.0.0
>>>>>>>> 88|Active |
>>>>>>>> 2|Apache Aries JMX
>>>>>>>> Blueprint API (1.1.5)|1.1.5
>>>>>>>> 89|Active |
>>>>>>>> 2|Apache Aries
>>>>>>>> Transaction Manager
>>>>>>>> (1.3.0)|1.3.0
>>>>>>>> 94|Active |
>>>>>>>> 3|Aries Remote Service
>>>>>>>> Admin Discovery Config
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 97|Active |
>>>>>>>> 3|Aries Remote Service
>>>>>>>> Admin provider TCP
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 110|Active |
>>>>>>>> 2|Apache Aries
>>>>>>>> Blueprint Annotation
>>>>>>>> API (1.0.1)|1.0.1
>>>>>>>> 120|Active |
>>>>>>>> 2|Apache Aries
>>>>>>>> Transaction Blueprint
>>>>>>>> (2.1.0)|2.1.0
>>>>>>>> 123|Active |
>>>>>>>> 2|Apache Aries JMX API
>>>>>>>> (1.1.5)|1.1.5
>>>>>>>> 130|Active |
>>>>>>>> 2|Apache Aries
>>>>>>>> Blueprint Annotation
>>>>>>>> Impl (1.0.1)|1.0.1
>>>>>>>> 132|Active |
>>>>>>>> 3|Aries Remote Service
>>>>>>>> Admin Discovery
>>>>>>>> Zookeeper
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 134|Active |
>>>>>>>> 3|Aries Remote Service
>>>>>>>> Admin Discovery Local
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 138|Active |
>>>>>>>> 3|Aries Remote Service
>>>>>>>> Admin Core
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 139|Active |
>>>>>>>> 2|Apache Aries JNDI RMI
>>>>>>>> Handler (1.0.0)|1.0.0
>>>>>>>> 143|Active |
>>>>>>>> 2|Apache Aries Proxy
>>>>>>>> Service (1.0.4)|1.0.4
>>>>>>>> 146|Active |
>>>>>>>> 2|Apache Aries SPI Fly
>>>>>>>> Dynamic Weaving Bundle
>>>>>>>> (1.0.8)|1.0.8
>>>>>>>> 147|Active |
>>>>>>>> 2|Aries JPA Container
>>>>>>>> blueprint integration
>>>>>>>> for Aries blueprint
>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>
>>>>>>>> 11|Active |
>>>>>>>> 4|Apache Felix File
>>>>>>>> Install (3.5.4)|3.5.4
>>>>>>>> 19|Active |
>>>>>>>> 4|Apache Felix Gogo
>>>>>>>> Shell (0.12.0)|0.12.0
>>>>>>>> 57|Active |
>>>>>>>> 4|Apache Felix Gogo
>>>>>>>> Command (0.16.0)|0.16.0
>>>>>>>> 104|Active |
>>>>>>>> 4|Apache Felix
>>>>>>>> Coordinator Service
>>>>>>>> (1.0.2)|1.0.2
>>>>>>>> 109|Active |
>>>>>>>> 4|Apache Felix Gogo
>>>>>>>> Runtime (0.16.2)|0.16.2
>>>>>>>> 114|Active |
>>>>>>>> 4|Apache Felix Web
>>>>>>>> Management Console
>>>>>>>> (1.2.8)|1.2.8
>>>>>>>> 148|Active |
>>>>>>>> 4|Apache Felix
>>>>>>>> Configuration Admin
>>>>>>>> Service (1.8.8)|1.8.8
>>>>>>>>
>>>>>>>> 0|Active |
>>>>>>>> 0|OSGi System Bundle
>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> WARNING: Computer
>>>>>>>> viruses can be
>>>>>>>> transmitted via email.
>>>>>>>> The recipient should
>>>>>>>> check this email and
>>>>>>>> any attachments for the
>>>>>>>> presence of viruses.
>>>>>>>> The company accepts no
>>>>>>>> liability for any
>>>>>>>> damage caused by any
>>>>>>>> virus transmitted by
>>>>>>>> this email. E-mail
>>>>>>>> transmission cannot be
>>>>>>>> guaranteed to be secure
>>>>>>>> or error-free as
>>>>>>>> information could be
>>>>>>>> intercepted, corrupted,
>>>>>>>> lost, destroyed, arrive
>>>>>>>> late or incomplete, or
>>>>>>>> contain viruses. The
>>>>>>>> sender therefore does
>>>>>>>> not accept liability
>>>>>>>> for any errors or
>>>>>>>> omissions in the
>>>>>>>> contents of this
>>>>>>>> message, which arise as
>>>>>>>> a result of e-mail
>>>>>>>> transmission.
>>>>>>>>
>>>>>>>> Warning: Although the
>>>>>>>> company has taken
>>>>>>>> reasonable precautions
>>>>>>>> to ensure no viruses
>>>>>>>> are present in this
>>>>>>>> email, the company
>>>>>>>> cannot accept
>>>>>>>> responsibility for any
>>>>>>>> loss or damage arising
>>>>>>>> from the use of this
>>>>>>>> email or attachments.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Raymond Aug�*
>>>>>>>> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>>>
>>>>>>>> Senior Software Architect
>>>>>>>> *Liferay, Inc.*
>>>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>>>> Board Member & EEG Co-Chair,
>>>>>>>> OSGi Alliance
>>>>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Raymond Aug�*
>>>>>> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>
>>>>>> Senior Software Architect *Liferay,
>>>>>> Inc.*
>>>>>> <http://www.liferay.com/> (@Liferay)
>>>>>> Board Member & EEG Co-Chair, OSGi
>>>>>> Alliance <http://osgi.org/>
>>>>>> (@OSGiAlliance)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Raymond Aug�*
>>>>> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>
>>>>> Senior Software Architect *Liferay, Inc.*
>>>>> <http://www.liferay.com/> (@Liferay)
>>>>> Board Member & EEG Co-Chair, OSGi Alliance
>>>>> <http://osgi.org/> (@OSGiAlliance)
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>>
>
Re: blueprint:cm multiple bundle but same config file
Posted by David Jencks <da...@yahoo.com>.
I’d like to make sure I understand what you are doing here…. IIUC during the build of your project you are generating multiple configuration files with the same or similar content, and each of these is loaded into a configuration which is bound to a particular bundle location? So, at build time you can change all the duplicate properties at once but if you need to change them later you have to alter n (== number of duplicate configs) independently? Whereas if you had multi-location support (and possibly multi-pid support such as DS provides) you could share a single Configuration and change the property while the framework was running in one place?
thanks
david jencks
> On Jul 11, 2016, at 1:42 PM, Brad Johnson <br...@mediadriver.com> wrote:
>
> Pablo,
>
> One possible solution to this problem that I'm currently looking at is using a configuration bundle along with my features bundle. In the configuration bundle I have all the cfg files and use properties placeholders ${value} to set the value for key/value.
>
> In the POM I load properties files using the Maven properties plugin and that lets me set a global set of properties values that can be used in filling in the cfg values. So if a port or URI is shared across a large number of them that automatically gets filled in. The features file can then specify the cfg files to install and what name to install them with.
>
> This gets rid of a lot of tedium and by using profiles I should be able to switch dev, test and production, and have the properties automatically set correctly.
>
> I'd like to modify this a bit so that dev, test and product cfg files are all created simultaneously and simply installed in different directories inside the configuration bundle. Then by using different features installs I can easily switch between the different configurations without having to tediously edit each configuration file.
>
> Brad
>
> On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
> Does Camel/Fuse even support DS? I haven't found any documentation saying otherwise. I've only found camel-scr which uses Felix-specific annotations and not DS.
>
> On 7 July 2016 at 14:32, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
> David,
>
> That is some pretty extreme and wild speculation alright. How does one use blueprint to not use OSGi appropriately? In the 5 years I've been consulting with Fuse/Karaf/OSGi and going to various clients not one of them used or uses DS. Not one. They all use bundles, services, and Camel with blueprint. The last time I worked with DS I didn't find it provided any serious advantage and added another layer that I'd have to teach my clients. Not that I wouldn't consider it or use it if I found a real advantage but I haven't.
>
> Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi 4.x land much less 5 or 6.
>
> So for Camel are you using the Java DSL?
>
> Brad
>
> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
> I don’t think karaf is at osgi R4.2 any more, I suggest you look at the osgi R5 or R6 config admin spec for “multi location”.
>
> You guys might be using blueprint every day, but there is no OSGI spec work to keep it up to date or even specify obviously necessary features such as config admin integration. If blueprint is so great why aren’t the proponents keeping the spec related to current OSGI? This is a part of my, admittedly extreme, theory that use of blueprint is related to not wanting to make the app actually use osgi appropriately.
>
> And, the project I work on every day uses DS exclusively and still finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
>
> david jencks
>
>
>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <seijoed@gmail.com <ma...@gmail.com>> wrote:
>>
>> It is in here; https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html <https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html>
>>
>> A bundle is in aries bound to the pid. So it is actually working as expected, bit of
>> a hassle since spring-dm allowed it.
>>
>> And yes selling DS into “regular" organizations is about as easy as selling snow in Alaska.
>>
>> /je
>>
>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>
>>> David,
>>>
>>> You live in a very different world than I do. In all the consulting I do with Fuse/karaf blueprint is used almost exclusively. I understand DS and its uses but also its limits and overhead. It's like telling me one should only use Camel Java DSL. That may be one's perspective but that isn't everyone's.
>>>
>>> Brad
>>>
>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>>> IMNSHO blueprint is only really plausible if you have a large amount of Spring based code and you need to convert it to be sort of osgi-compatible really quickly without understanding osgi or the code. Otherwise taking the time to understand DS and use it is much more satisfactory. DS provides this configuration override ability with support for multiple pids, although only one of the pids can turn out to be a factory configuration. There’s no obvious way of correlating factory configurations, so this restriction makes some sense.
>>>
>>> I don’t think there really are any blueprint folks. The cm stuff, while obviously required to make the spec remotely plausible, hasn’t made it into the spec in the many many years it’s been sitting around.
>>>
>>> david jencks
>>>
>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>>
>>>> If I were to sit down with the blueprint folks today to create a wish list one thing I'd like to see is for an ability to have a configuration hierarchy specified with parent/child relationships much like one has in Maven. Have a base configuration file and be able to have another cfg file specify that one as its parent. Override properties or add them to the child. When the configuration admin fires up it would read up the chain and construct the properties.
>>>>
>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>> Ray,
>>>>
>>>> If I understand your question right the answer is the Aries extension is referencing configuration. In karaf/fuse for example the following:
>>>>
>>>> <cm:property-placeholder persistent-id="com.my.foo" update-strategy="reload">
>>>>
>>>> will load properties from etc/com.my.foo.cfg
>>>>
>>>> Installing that file is done either manually or by use of a features file.
>>>>
>>>> Whenever I've attempted to use the PID in more than one bundle it has failed and I don't think it is permitted. That's a problem I think and something that should be fixed through some other configuration management mechanism. Making microservices that might share common properties, for example, becomes problematic in that regard and I've resorted to using my own OSGi services to overcome that problem.
>>>>
>>>> Brad
>>>>
>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
>>>> Ok, so after a brief review the cm schema is an Aries extension and it doesn't appear to support the location binding.
>>>>
>>>> However, it's unclear to me whether this extension is creating the configuration or merely referencing one from outside.
>>>>
>>>> Any Aries gurus can answer that?
>>>>
>>>> - Ray
>>>>
>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>>>> I’m not really familiar with blueprint cm but I’d expect that to indicate which pid to use to fetch the config from config admin and in the ... how to map configuration propertiething blueprint substitution knows about. Is that really instructions to create a new configuration and populate it with data (what a management agent does)?
>>>>
>>>> david jencks
>>>>
>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
>>>>>
>>>>> David, I agree with everything you've said, however this looks like blueprint being the agent here:
>>>>>
>>>>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>>>>> ...
>>>>> </cm:property-placeholder>
>>>>>
>>>>> - Ray
>>>>>
>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>>>>> No, blueprint cm shouldn’t really know about the multi-location. The management agent that is creating the configuration should be setting the bundle location to the multi-location ”?”.
>>>>>
>>>>> david jencks
>>>>>
>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>>>>>
>>>>>> I see and would it possible to configure which method is invoked from Blueprint?
>>>>>>
>>>>>> This is how I do it:
>>>>>>
>>>>>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>>>>>> ...
>>>>>> </cm:property-placeholder>
>>>>>>
>>>>>> is there perhaps some blueprint property where I can tune the second argument in the createFactoryConfiguration?
>>>>>>
>>>>>> Because it looks like the fact of using config admin through blueprint binds the PID to the first bundle using it
>>>>>>
>>>>>>
>>>>>> best
>>>>>> Pablo
>>>>>>
>>>>>>
>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>> As long as configurations are not bound to a bundle they can be used by any bundle.
>>>>>>>
>>>>>>> The exception clearly shows that the configuration is bound to a bundle.
>>>>>>>
>>>>>>> Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>>>>>>
>>>>>>>
>>>>>>> HTH,
>>>>>>> - Ray
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>>>>> I don't think that's possible.
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>>>>>> Hello All,
>>>>>>>
>>>>>>> Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
>>>>>>>
>>>>>>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm <http://org.osgi.service.cm/>.ManagedService, id=214, bundle=86/initial@reference:file:../plugin-1/ <mailto:bundle=86/initial@reference:file:../plugin-1/>]: No visibility to configuration bound to initial@reference:file:../plugin-2/ <mailto:initial@reference:file:../plugin-2/>
>>>>>>>
>>>>>>>
>>>>>>> I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959 <https://issues.jboss.org/browse/ENTESB-3959>
>>>>>>>
>>>>>>>
>>>>>>> However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
>>>>>>>
>>>>>>>
>>>>>>> As a workaround I can make a config file per bundle that needs it....
>>>>>>>
>>>>>>> As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
>>>>>>>
>>>>>>> ID|State |Level|Name
>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>>> 67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>>>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
>>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
>>>>>>> 147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>>
>>>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>>>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>>>>> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
>>>>>>> 148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
>>>>>>>
>>>>>>> 0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
>>>>>>>
>>>>>>> Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>>>
>>>>
>>>
>>>
>>
>
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
Pablo,
One possible solution to this problem that I'm currently looking at is
using a configuration bundle along with my features bundle. In the
configuration bundle I have all the cfg files and use properties
placeholders ${value} to set the value for key/value.
In the POM I load properties files using the Maven properties plugin and
that lets me set a global set of properties values that can be used in
filling in the cfg values. So if a port or URI is shared across a large
number of them that automatically gets filled in. The features file can
then specify the cfg files to install and what name to install them with.
This gets rid of a lot of tedium and by using profiles I should be able to
switch dev, test and production, and have the properties automatically set
correctly.
I'd like to modify this a bit so that dev, test and product cfg files are
all created simultaneously and simply installed in different directories
inside the configuration bundle. Then by using different features installs
I can easily switch between the different configurations without having to
tediously edit each configuration file.
Brad
On Sat, Jul 9, 2016 at 11:32 AM, Matt Sicker <bo...@gmail.com> wrote:
> Does Camel/Fuse even support DS? I haven't found any documentation saying
> otherwise. I've only found camel-scr which uses Felix-specific annotations
> and not DS.
>
> On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com>
> wrote:
>
>> David,
>>
>> That is some pretty extreme and wild speculation alright. How does one
>> use blueprint to not use OSGi appropriately? In the 5 years I've been
>> consulting with Fuse/Karaf/OSGi and going to various clients not one of
>> them used or uses DS. Not one. They all use bundles, services, and Camel
>> with blueprint. The last time I worked with DS I didn't find it provided
>> any serious advantage and added another layer that I'd have to teach my
>> clients. Not that I wouldn't consider it or use it if I found a real
>> advantage but I haven't.
>>
>> Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi 4.x
>> land much less 5 or 6.
>>
>> So for Camel are you using the Java DSL?
>>
>> Brad
>>
>> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>
>>> I don’t think karaf is at osgi R4.2 any more, I suggest you look at the
>>> osgi R5 or R6 config admin spec for “multi location”.
>>>
>>> You guys might be using blueprint every day, but there is no OSGI spec
>>> work to keep it up to date or even specify obviously necessary features
>>> such as config admin integration. If blueprint is so great why aren’t the
>>> proponents keeping the spec related to current OSGI? This is a part of my,
>>> admittedly extreme, theory that use of blueprint is related to not wanting
>>> to make the app actually use osgi appropriately.
>>>
>>> And, the project I work on every day uses DS exclusively and still finds
>>> plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>>
>>> david jencks
>>>
>>>
>>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com> wrote:
>>>
>>> It is in here;
>>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>>
>>> A bundle is in aries bound to the pid. So it is actually working as
>>> expected, bit of
>>> a hassle since spring-dm allowed it.
>>>
>>> And yes selling DS into “regular" organizations is about as easy as
>>> selling snow in Alaska.
>>>
>>> /je
>>>
>>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <br...@mediadriver.com>
>>> wrote:
>>>
>>> David,
>>>
>>> You live in a very different world than I do. In all the consulting I
>>> do with Fuse/karaf blueprint is used almost exclusively. I understand DS
>>> and its uses but also its limits and overhead. It's like telling me one
>>> should only use Camel Java DSL. That may be one's perspective but that
>>> isn't everyone's.
>>>
>>> Brad
>>>
>>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <da...@yahoo.com>
>>> wrote:
>>>
>>>> IMNSHO blueprint is only really plausible if you have a large amount of
>>>> Spring based code and you need to convert it to be sort of osgi-compatible
>>>> really quickly without understanding osgi or the code. Otherwise taking
>>>> the time to understand DS and use it is much more satisfactory. DS
>>>> provides this configuration override ability with support for multiple
>>>> pids, although only one of the pids can turn out to be a factory
>>>> configuration. There’s no obvious way of correlating factory
>>>> configurations, so this restriction makes some sense.
>>>>
>>>> I don’t think there really are any blueprint folks. The cm stuff,
>>>> while obviously required to make the spec remotely plausible, hasn’t made
>>>> it into the spec in the many many years it’s been sitting around.
>>>>
>>>> david jencks
>>>>
>>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <br...@mediadriver.com>
>>>> wrote:
>>>>
>>>> If I were to sit down with the blueprint folks today to create a wish
>>>> list one thing I'd like to see is for an ability to have a configuration
>>>> hierarchy specified with parent/child relationships much like one has in
>>>> Maven. Have a base configuration file and be able to have another cfg file
>>>> specify that one as its parent. Override properties or add them to the
>>>> child. When the configuration admin fires up it would read up the chain
>>>> and construct the properties.
>>>>
>>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>>> brad.johnson@mediadriver.com> wrote:
>>>>
>>>>> Ray,
>>>>>
>>>>> If I understand your question right the answer is the Aries extension
>>>>> is referencing configuration. In karaf/fuse for example the following:
>>>>>
>>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>>> update-strategy="reload">
>>>>>
>>>>> will load properties from etc/com.my.foo.cfg
>>>>>
>>>>> Installing that file is done either manually or by use of a features
>>>>> file.
>>>>>
>>>>> Whenever I've attempted to use the PID in more than one bundle it has
>>>>> failed and I don't think it is permitted. That's a problem I think and
>>>>> something that should be fixed through some other configuration management
>>>>> mechanism. Making microservices that might share common properties, for
>>>>> example, becomes problematic in that regard and I've resorted to using my
>>>>> own OSGi services to overcome that problem.
>>>>>
>>>>> Brad
>>>>>
>>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <
>>>>> raymond.auge@liferay.com> wrote:
>>>>>
>>>>>> Ok, so after a brief review the cm schema is an Aries extension and
>>>>>> it doesn't appear to support the location binding.
>>>>>>
>>>>>> However, it's unclear to me whether this extension is creating the
>>>>>> configuration or merely referencing one from outside.
>>>>>>
>>>>>> Any Aries gurus can answer that?
>>>>>>
>>>>>> - Ray
>>>>>>
>>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <david_jencks@yahoo.com
>>>>>> > wrote:
>>>>>>
>>>>>>> I’m not really familiar with blueprint cm but I’d expect that to
>>>>>>> indicate which pid to use to fetch the config from config admin and in the
>>>>>>> ... how to map configuration propertiething blueprint substitution knows
>>>>>>> about. Is that really instructions to create a new configuration and
>>>>>>> populate it with data (what a management agent does)?
>>>>>>>
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> David, I agree with everything you've said, however this looks like
>>>>>>> blueprint being the agent here:
>>>>>>>
>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>> update-strategy="reload">
>>>>>>> ...
>>>>>>> </cm:property-placeholder>
>>>>>>>
>>>>>>> - Ray
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <
>>>>>>> david_jencks@yahoo.com> wrote:
>>>>>>>
>>>>>>>> No, blueprint cm shouldn’t really know about the multi-location.
>>>>>>>> The management agent that is creating the configuration should be setting
>>>>>>>> the bundle location to the multi-location ”?”.
>>>>>>>>
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>
>>>>>>>> I see and would it possible to configure which method is invoked
>>>>>>>> from Blueprint?
>>>>>>>>
>>>>>>>> This is how I do it:
>>>>>>>>
>>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>>> update-strategy="reload">
>>>>>>>> ...
>>>>>>>> </cm:property-placeholder>
>>>>>>>>
>>>>>>>> is there perhaps some blueprint property where I can tune the
>>>>>>>> second argument in the createFactoryConfiguration?
>>>>>>>>
>>>>>>>> Because it looks like the fact of using config admin through
>>>>>>>> blueprint binds the PID to the first bundle using it
>>>>>>>>
>>>>>>>>
>>>>>>>> best
>>>>>>>> Pablo
>>>>>>>>
>>>>>>>>
>>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>>
>>>>>>>> As long as configurations are not bound to a bundle they can be
>>>>>>>> used by any bundle.
>>>>>>>>
>>>>>>>> The exception clearly shows that the configuration is bound to a
>>>>>>>> bundle.
>>>>>>>>
>>>>>>>> Creating an unbound configuration requires passing a "?" as the
>>>>>>>> second arguments to getConfiguration/createFactoryConfiguration methods of
>>>>>>>> CM.
>>>>>>>>
>>>>>>>>
>>>>>>>> HTH,
>>>>>>>> - Ray
>>>>>>>>
>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>>
>>>>>>>>> I don't think that's possible.
>>>>>>>>>
>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>>
>>>>>>>>>> Hello All,
>>>>>>>>>>
>>>>>>>>>> Is it possible to use same config file from multiple
>>>>>>>>>> bundles while using Config Admin with blueprint Blueprint? Because, I can't
>>>>>>>>>> manage to do that, I get the following error:
>>>>>>>>>>
>>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No visibility to
>>>>>>>>>> configuration bound to initial@reference:file:../plugin-2/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> However, I fear that this is a problem in the aries blueprint
>>>>>>>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>>> basically using blueprint:cm
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As a workaround I can make a config file per bundle that needs
>>>>>>>>>> it....
>>>>>>>>>>
>>>>>>>>>> As follows the versions and bundles that I'm using related to the
>>>>>>>>>> container (Running on top of Equinox 3.11):
>>>>>>>>>>
>>>>>>>>>> ID|State |Level|Name
>>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>>>>>>>>> DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology
>>>>>>>>>> Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo
>>>>>>>>>> Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler
>>>>>>>>>> (1.1.0)|1.1.0
>>>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
>>>>>>>>>> Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service
>>>>>>>>>> Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>> (1.1.1)|1.1.1
>>>>>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy
>>>>>>>>>> Runtimes (1.0.0)|1.0.0
>>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>> Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>>> (2.1.0)|2.1.0
>>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>> Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>>> Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler
>>>>>>>>>> (1.0.0)|1.0.0
>>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving
>>>>>>>>>> Bundle (1.0.8)|1.0.8
>>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint integration
>>>>>>>>>> for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>>
>>>>>>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>>>>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>>>>>>> (1.2.8)|1.2.8
>>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin Service
>>>>>>>>>> (1.8.8)|1.8.8
>>>>>>>>>>
>>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> WARNING: Computer viruses can be transmitted via email. The
>>>>>>>>>> recipient should check this email and any attachments for the presence of
>>>>>>>>>> viruses. The company accepts no liability for any damage caused by any
>>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>>
>>>>>>>>>> Warning: Although the company has taken reasonable precautions to
>>>>>>>>>> ensure no viruses are present in this email, the company cannot accept
>>>>>>>>>> responsibility for any loss or damage arising from the use of this email or
>>>>>>>>>> attachments.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>> (@rotty3000)
>>>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>>>>>> (@Liferay)
>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>>> (@OSGiAlliance)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>> (@rotty3000)
>>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>>>>> (@Liferay)
>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>> (@OSGiAlliance)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>> (@rotty3000)
>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>>>> (@Liferay)
>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>> (@OSGiAlliance)
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Matt Sicker <bo...@gmail.com>.
Does Camel/Fuse even support DS? I haven't found any documentation saying
otherwise. I've only found camel-scr which uses Felix-specific annotations
and not DS.
On 7 July 2016 at 14:32, Brad Johnson <br...@mediadriver.com> wrote:
> David,
>
> That is some pretty extreme and wild speculation alright. How does one
> use blueprint to not use OSGi appropriately? In the 5 years I've been
> consulting with Fuse/Karaf/OSGi and going to various clients not one of
> them used or uses DS. Not one. They all use bundles, services, and Camel
> with blueprint. The last time I worked with DS I didn't find it provided
> any serious advantage and added another layer that I'd have to teach my
> clients. Not that I wouldn't consider it or use it if I found a real
> advantage but I haven't.
>
> Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi 4.x
> land much less 5 or 6.
>
> So for Camel are you using the Java DSL?
>
> Brad
>
> On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <da...@yahoo.com>
> wrote:
>
>> I don’t think karaf is at osgi R4.2 any more, I suggest you look at the
>> osgi R5 or R6 config admin spec for “multi location”.
>>
>> You guys might be using blueprint every day, but there is no OSGI spec
>> work to keep it up to date or even specify obviously necessary features
>> such as config admin integration. If blueprint is so great why aren’t the
>> proponents keeping the spec related to current OSGI? This is a part of my,
>> admittedly extreme, theory that use of blueprint is related to not wanting
>> to make the app actually use osgi appropriately.
>>
>> And, the project I work on every day uses DS exclusively and still finds
>> plenty of ways to abuse osgi in all sorts of inventive ways :-)
>>
>> david jencks
>>
>>
>> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com> wrote:
>>
>> It is in here;
>> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>>
>> A bundle is in aries bound to the pid. So it is actually working as
>> expected, bit of
>> a hassle since spring-dm allowed it.
>>
>> And yes selling DS into “regular" organizations is about as easy as
>> selling snow in Alaska.
>>
>> /je
>>
>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <br...@mediadriver.com>
>> wrote:
>>
>> David,
>>
>> You live in a very different world than I do. In all the consulting I do
>> with Fuse/karaf blueprint is used almost exclusively. I understand DS and
>> its uses but also its limits and overhead. It's like telling me one should
>> only use Camel Java DSL. That may be one's perspective but that isn't
>> everyone's.
>>
>> Brad
>>
>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>
>>> IMNSHO blueprint is only really plausible if you have a large amount of
>>> Spring based code and you need to convert it to be sort of osgi-compatible
>>> really quickly without understanding osgi or the code. Otherwise taking
>>> the time to understand DS and use it is much more satisfactory. DS
>>> provides this configuration override ability with support for multiple
>>> pids, although only one of the pids can turn out to be a factory
>>> configuration. There’s no obvious way of correlating factory
>>> configurations, so this restriction makes some sense.
>>>
>>> I don’t think there really are any blueprint folks. The cm stuff, while
>>> obviously required to make the spec remotely plausible, hasn’t made it into
>>> the spec in the many many years it’s been sitting around.
>>>
>>> david jencks
>>>
>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <br...@mediadriver.com>
>>> wrote:
>>>
>>> If I were to sit down with the blueprint folks today to create a wish
>>> list one thing I'd like to see is for an ability to have a configuration
>>> hierarchy specified with parent/child relationships much like one has in
>>> Maven. Have a base configuration file and be able to have another cfg file
>>> specify that one as its parent. Override properties or add them to the
>>> child. When the configuration admin fires up it would read up the chain
>>> and construct the properties.
>>>
>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>>> brad.johnson@mediadriver.com> wrote:
>>>
>>>> Ray,
>>>>
>>>> If I understand your question right the answer is the Aries extension
>>>> is referencing configuration. In karaf/fuse for example the following:
>>>>
>>>> <cm:property-placeholder persistent-id="com.my.foo"
>>>> update-strategy="reload">
>>>>
>>>> will load properties from etc/com.my.foo.cfg
>>>>
>>>> Installing that file is done either manually or by use of a features
>>>> file.
>>>>
>>>> Whenever I've attempted to use the PID in more than one bundle it has
>>>> failed and I don't think it is permitted. That's a problem I think and
>>>> something that should be fixed through some other configuration management
>>>> mechanism. Making microservices that might share common properties, for
>>>> example, becomes problematic in that regard and I've resorted to using my
>>>> own OSGi services to overcome that problem.
>>>>
>>>> Brad
>>>>
>>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <raymond.auge@liferay.com
>>>> > wrote:
>>>>
>>>>> Ok, so after a brief review the cm schema is an Aries extension and it
>>>>> doesn't appear to support the location binding.
>>>>>
>>>>> However, it's unclear to me whether this extension is creating the
>>>>> configuration or merely referencing one from outside.
>>>>>
>>>>> Any Aries gurus can answer that?
>>>>>
>>>>> - Ray
>>>>>
>>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <da...@yahoo.com>
>>>>> wrote:
>>>>>
>>>>>> I’m not really familiar with blueprint cm but I’d expect that to
>>>>>> indicate which pid to use to fetch the config from config admin and in the
>>>>>> ... how to map configuration propertiething blueprint substitution knows
>>>>>> about. Is that really instructions to create a new configuration and
>>>>>> populate it with data (what a management agent does)?
>>>>>>
>>>>>> david jencks
>>>>>>
>>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com>
>>>>>> wrote:
>>>>>>
>>>>>> David, I agree with everything you've said, however this looks like
>>>>>> blueprint being the agent here:
>>>>>>
>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>> update-strategy="reload">
>>>>>> ...
>>>>>> </cm:property-placeholder>
>>>>>>
>>>>>> - Ray
>>>>>>
>>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <david_jencks@yahoo.com
>>>>>> > wrote:
>>>>>>
>>>>>>> No, blueprint cm shouldn’t really know about the multi-location.
>>>>>>> The management agent that is creating the configuration should be setting
>>>>>>> the bundle location to the multi-location ”?”.
>>>>>>>
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <
>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>
>>>>>>> I see and would it possible to configure which method is invoked
>>>>>>> from Blueprint?
>>>>>>>
>>>>>>> This is how I do it:
>>>>>>>
>>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>>> update-strategy="reload">
>>>>>>> ...
>>>>>>> </cm:property-placeholder>
>>>>>>>
>>>>>>> is there perhaps some blueprint property where I can tune the second
>>>>>>> argument in the createFactoryConfiguration?
>>>>>>>
>>>>>>> Because it looks like the fact of using config admin through
>>>>>>> blueprint binds the PID to the first bundle using it
>>>>>>>
>>>>>>>
>>>>>>> best
>>>>>>> Pablo
>>>>>>>
>>>>>>>
>>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>>
>>>>>>> As long as configurations are not bound to a bundle they can be used
>>>>>>> by any bundle.
>>>>>>>
>>>>>>> The exception clearly shows that the configuration is bound to a
>>>>>>> bundle.
>>>>>>>
>>>>>>> Creating an unbound configuration requires passing a "?" as the
>>>>>>> second arguments to getConfiguration/createFactoryConfiguration methods of
>>>>>>> CM.
>>>>>>>
>>>>>>>
>>>>>>> HTH,
>>>>>>> - Ray
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>>
>>>>>>>> I don't think that's possible.
>>>>>>>>
>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>>
>>>>>>>>> Hello All,
>>>>>>>>>
>>>>>>>>> Is it possible to use same config file from multiple
>>>>>>>>> bundles while using Config Admin with blueprint Blueprint? Because, I can't
>>>>>>>>> manage to do that, I get the following error:
>>>>>>>>>
>>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No visibility to
>>>>>>>>> configuration bound to initial@reference:file:../plugin-2/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I saw in this jira a bug opened:
>>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> However, I fear that this is a problem in the aries blueprint
>>>>>>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>>> basically using blueprint:cm
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As a workaround I can make a config file per bundle that needs
>>>>>>>>> it....
>>>>>>>>>
>>>>>>>>> As follows the versions and bundles that I'm using related to the
>>>>>>>>> container (Running on top of Equinox 3.11):
>>>>>>>>>
>>>>>>>>> ID|State |Level|Name
>>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>>>>>>>> DynamicMBean services (1.1.5)|1.1.5
>>>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology
>>>>>>>>> Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo
>>>>>>>>> Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
>>>>>>>>> Fragment Bundle (1.0.0)|1.0.0
>>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>>>>>>> (1.0.4)|1.0.4
>>>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service
>>>>>>>>> Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>> (1.1.1)|1.1.1
>>>>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy
>>>>>>>>> Runtimes (1.0.0)|1.0.0
>>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API
>>>>>>>>> (1.1.5)|1.1.5
>>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>>> (1.3.0)|1.3.0
>>>>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>> Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>>> (2.1.0)|2.1.0
>>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>>>>>>>> (1.0.1)|1.0.1
>>>>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>>> Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local
>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>>>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving
>>>>>>>>> Bundle (1.0.8)|1.0.8
>>>>>>>>> 147|Active | 2|Aries JPA Container blueprint integration
>>>>>>>>> for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>>
>>>>>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>>>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>>> (1.0.2)|1.0.2
>>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>>>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>>>>>> (1.2.8)|1.2.8
>>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin Service
>>>>>>>>> (1.8.8)|1.8.8
>>>>>>>>>
>>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> WARNING: Computer viruses can be transmitted via email. The
>>>>>>>>> recipient should check this email and any attachments for the presence of
>>>>>>>>> viruses. The company accepts no liability for any damage caused by any
>>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>>
>>>>>>>>> Warning: Although the company has taken reasonable precautions to
>>>>>>>>> ensure no viruses are present in this email, the company cannot accept
>>>>>>>>> responsibility for any loss or damage arising from the use of this email or
>>>>>>>>> attachments.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>> (@rotty3000)
>>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>>>>> (@Liferay)
>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>>> (@OSGiAlliance)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>> (@rotty3000)
>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>>>> (@Liferay)
>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>> (@OSGiAlliance)
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>> (@rotty3000)
>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>>> (@Liferay)
>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>> (@OSGiAlliance)
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
--
Matt Sicker <bo...@gmail.com>
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
David,
That is some pretty extreme and wild speculation alright. How does one use
blueprint to not use OSGi appropriately? In the 5 years I've been
consulting with Fuse/Karaf/OSGi and going to various clients not one of
them used or uses DS. Not one. They all use bundles, services, and Camel
with blueprint. The last time I worked with DS I didn't find it provided
any serious advantage and added another layer that I'd have to teach my
clients. Not that I wouldn't consider it or use it if I found a real
advantage but I haven't.
Red Hat is still shipping Karaf 2.x with Fuse so it is still in OSGi 4.x
land much less 5 or 6.
So for Camel are you using the Java DSL?
Brad
On Thu, Jul 7, 2016 at 1:56 PM, David Jencks <da...@yahoo.com> wrote:
> I don’t think karaf is at osgi R4.2 any more, I suggest you look at the
> osgi R5 or R6 config admin spec for “multi location”.
>
> You guys might be using blueprint every day, but there is no OSGI spec
> work to keep it up to date or even specify obviously necessary features
> such as config admin integration. If blueprint is so great why aren’t the
> proponents keeping the spec related to current OSGI? This is a part of my,
> admittedly extreme, theory that use of blueprint is related to not wanting
> to make the app actually use osgi appropriately.
>
> And, the project I work on every day uses DS exclusively and still finds
> plenty of ways to abuse osgi in all sorts of inventive ways :-)
>
> david jencks
>
>
> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com> wrote:
>
> It is in here;
> https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html
>
> A bundle is in aries bound to the pid. So it is actually working as
> expected, bit of
> a hassle since spring-dm allowed it.
>
> And yes selling DS into “regular" organizations is about as easy as
> selling snow in Alaska.
>
> /je
>
> On Jul 7, 2016, at 12:00 PM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
> David,
>
> You live in a very different world than I do. In all the consulting I do
> with Fuse/karaf blueprint is used almost exclusively. I understand DS and
> its uses but also its limits and overhead. It's like telling me one should
> only use Camel Java DSL. That may be one's perspective but that isn't
> everyone's.
>
> Brad
>
> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <da...@yahoo.com>
> wrote:
>
>> IMNSHO blueprint is only really plausible if you have a large amount of
>> Spring based code and you need to convert it to be sort of osgi-compatible
>> really quickly without understanding osgi or the code. Otherwise taking
>> the time to understand DS and use it is much more satisfactory. DS
>> provides this configuration override ability with support for multiple
>> pids, although only one of the pids can turn out to be a factory
>> configuration. There’s no obvious way of correlating factory
>> configurations, so this restriction makes some sense.
>>
>> I don’t think there really are any blueprint folks. The cm stuff, while
>> obviously required to make the spec remotely plausible, hasn’t made it into
>> the spec in the many many years it’s been sitting around.
>>
>> david jencks
>>
>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <br...@mediadriver.com>
>> wrote:
>>
>> If I were to sit down with the blueprint folks today to create a wish
>> list one thing I'd like to see is for an ability to have a configuration
>> hierarchy specified with parent/child relationships much like one has in
>> Maven. Have a base configuration file and be able to have another cfg file
>> specify that one as its parent. Override properties or add them to the
>> child. When the configuration admin fires up it would read up the chain
>> and construct the properties.
>>
>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
>> brad.johnson@mediadriver.com> wrote:
>>
>>> Ray,
>>>
>>> If I understand your question right the answer is the Aries extension is
>>> referencing configuration. In karaf/fuse for example the following:
>>>
>>> <cm:property-placeholder persistent-id="com.my.foo"
>>> update-strategy="reload">
>>>
>>> will load properties from etc/com.my.foo.cfg
>>>
>>> Installing that file is done either manually or by use of a features
>>> file.
>>>
>>> Whenever I've attempted to use the PID in more than one bundle it has
>>> failed and I don't think it is permitted. That's a problem I think and
>>> something that should be fixed through some other configuration management
>>> mechanism. Making microservices that might share common properties, for
>>> example, becomes problematic in that regard and I've resorted to using my
>>> own OSGi services to overcome that problem.
>>>
>>> Brad
>>>
>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <ra...@liferay.com>
>>> wrote:
>>>
>>>> Ok, so after a brief review the cm schema is an Aries extension and it
>>>> doesn't appear to support the location binding.
>>>>
>>>> However, it's unclear to me whether this extension is creating the
>>>> configuration or merely referencing one from outside.
>>>>
>>>> Any Aries gurus can answer that?
>>>>
>>>> - Ray
>>>>
>>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <da...@yahoo.com>
>>>> wrote:
>>>>
>>>>> I’m not really familiar with blueprint cm but I’d expect that to
>>>>> indicate which pid to use to fetch the config from config admin and in the
>>>>> ... how to map configuration propertiething blueprint substitution knows
>>>>> about. Is that really instructions to create a new configuration and
>>>>> populate it with data (what a management agent does)?
>>>>>
>>>>> david jencks
>>>>>
>>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com>
>>>>> wrote:
>>>>>
>>>>> David, I agree with everything you've said, however this looks like
>>>>> blueprint being the agent here:
>>>>>
>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>> update-strategy="reload">
>>>>> ...
>>>>> </cm:property-placeholder>
>>>>>
>>>>> - Ray
>>>>>
>>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <da...@yahoo.com>
>>>>> wrote:
>>>>>
>>>>>> No, blueprint cm shouldn’t really know about the multi-location. The
>>>>>> management agent that is creating the configuration should be setting the
>>>>>> bundle location to the multi-location ”?”.
>>>>>>
>>>>>> david jencks
>>>>>>
>>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
>>>>>> wrote:
>>>>>>
>>>>>> I see and would it possible to configure which method is invoked from
>>>>>> Blueprint?
>>>>>>
>>>>>> This is how I do it:
>>>>>>
>>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>>> update-strategy="reload">
>>>>>> ...
>>>>>> </cm:property-placeholder>
>>>>>>
>>>>>> is there perhaps some blueprint property where I can tune the second
>>>>>> argument in the createFactoryConfiguration?
>>>>>>
>>>>>> Because it looks like the fact of using config admin through
>>>>>> blueprint binds the PID to the first bundle using it
>>>>>>
>>>>>>
>>>>>> best
>>>>>> Pablo
>>>>>>
>>>>>>
>>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>>
>>>>>> As long as configurations are not bound to a bundle they can be used
>>>>>> by any bundle.
>>>>>>
>>>>>> The exception clearly shows that the configuration is bound to a
>>>>>> bundle.
>>>>>>
>>>>>> Creating an unbound configuration requires passing a "?" as the
>>>>>> second arguments to getConfiguration/createFactoryConfiguration methods of
>>>>>> CM.
>>>>>>
>>>>>>
>>>>>> HTH,
>>>>>> - Ray
>>>>>>
>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>>
>>>>>>> I don't think that's possible.
>>>>>>>
>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>>
>>>>>>>> Hello All,
>>>>>>>>
>>>>>>>> Is it possible to use same config file from multiple
>>>>>>>> bundles while using Config Admin with blueprint Blueprint? Because, I can't
>>>>>>>> manage to do that, I get the following error:
>>>>>>>>
>>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No visibility to
>>>>>>>> configuration bound to initial@reference:file:../plugin-2/
>>>>>>>>
>>>>>>>>
>>>>>>>> I saw in this jira a bug opened:
>>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>>
>>>>>>>>
>>>>>>>> However, I fear that this is a problem in the aries blueprint
>>>>>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>>> basically using blueprint:cm
>>>>>>>>
>>>>>>>>
>>>>>>>> As a workaround I can make a config file per bundle that needs
>>>>>>>> it....
>>>>>>>>
>>>>>>>> As follows the versions and bundles that I'm using related to the
>>>>>>>> container (Running on top of Equinox 3.11):
>>>>>>>>
>>>>>>>> ID|State |Level|Name
>>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>>>>>>> DynamicMBean services (1.1.5)|1.1.5
>>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo
>>>>>>>> Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core
>>>>>>>> (1.1.5)|1.1.5
>>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
>>>>>>>> Fragment Bundle (1.0.0)|1.0.0
>>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>>>>>> (1.0.4)|1.0.4
>>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>>>> 67|Active | 3|Aries Remote Service Admin Service Provider
>>>>>>>> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>> (1.1.1)|1.1.1
>>>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy
>>>>>>>> Runtimes (1.0.0)|1.0.0
>>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>>> (1.3.0)|1.3.0
>>>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>>>>>> (1.0.1)|1.0.1
>>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>>>> (2.1.0)|2.1.0
>>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>>>>>>> (1.0.1)|1.0.1
>>>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery
>>>>>>>> Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
>>>>>>>> (1.0.8)|1.0.8
>>>>>>>> 147|Active | 2|Aries JPA Container blueprint integration
>>>>>>>> for Aries blueprint (1.0.4)|1.0.4
>>>>>>>>
>>>>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>>> (1.0.2)|1.0.2
>>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>>>>> (1.2.8)|1.2.8
>>>>>>>> 148|Active | 4|Apache Felix Configuration Admin Service
>>>>>>>> (1.8.8)|1.8.8
>>>>>>>>
>>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> WARNING: Computer viruses can be transmitted via email. The
>>>>>>>> recipient should check this email and any attachments for the presence of
>>>>>>>> viruses. The company accepts no liability for any damage caused by any
>>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>>
>>>>>>>> Warning: Although the company has taken reasonable precautions to
>>>>>>>> ensure no viruses are present in this email, the company cannot accept
>>>>>>>> responsibility for any loss or damage arising from the use of this email or
>>>>>>>> attachments.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>> (@rotty3000)
>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>>>> (@Liferay)
>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>>> (@OSGiAlliance)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>> (@rotty3000)
>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>>> (@Liferay)
>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>> (@OSGiAlliance)
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>> (@rotty3000)
>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>> (@Liferay)
>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>> (@OSGiAlliance)
>>>>
>>>
>>>
>>
>>
>
>
>
Re: blueprint:cm multiple bundle but same config file
Posted by David Jencks <da...@yahoo.com>.
I don’t think karaf is at osgi R4.2 any more, I suggest you look at the osgi R5 or R6 config admin spec for “multi location”.
You guys might be using blueprint every day, but there is no OSGI spec work to keep it up to date or even specify obviously necessary features such as config admin integration. If blueprint is so great why aren’t the proponents keeping the spec related to current OSGI? This is a part of my, admittedly extreme, theory that use of blueprint is related to not wanting to make the app actually use osgi appropriately.
And, the project I work on every day uses DS exclusively and still finds plenty of ways to abuse osgi in all sorts of inventive ways :-)
david jencks
> On Jul 7, 2016, at 11:11 AM, Johan Edstrom <se...@gmail.com> wrote:
>
> It is in here; https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html <https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html>
>
> A bundle is in aries bound to the pid. So it is actually working as expected, bit of
> a hassle since spring-dm allowed it.
>
> And yes selling DS into “regular" organizations is about as easy as selling snow in Alaska.
>
> /je
>
>> On Jul 7, 2016, at 12:00 PM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>
>> David,
>>
>> You live in a very different world than I do. In all the consulting I do with Fuse/karaf blueprint is used almost exclusively. I understand DS and its uses but also its limits and overhead. It's like telling me one should only use Camel Java DSL. That may be one's perspective but that isn't everyone's.
>>
>> Brad
>>
>> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>> IMNSHO blueprint is only really plausible if you have a large amount of Spring based code and you need to convert it to be sort of osgi-compatible really quickly without understanding osgi or the code. Otherwise taking the time to understand DS and use it is much more satisfactory. DS provides this configuration override ability with support for multiple pids, although only one of the pids can turn out to be a factory configuration. There’s no obvious way of correlating factory configurations, so this restriction makes some sense.
>>
>> I don’t think there really are any blueprint folks. The cm stuff, while obviously required to make the spec remotely plausible, hasn’t made it into the spec in the many many years it’s been sitting around.
>>
>> david jencks
>>
>>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>
>>> If I were to sit down with the blueprint folks today to create a wish list one thing I'd like to see is for an ability to have a configuration hierarchy specified with parent/child relationships much like one has in Maven. Have a base configuration file and be able to have another cfg file specify that one as its parent. Override properties or add them to the child. When the configuration admin fires up it would read up the chain and construct the properties.
>>>
>>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>> Ray,
>>>
>>> If I understand your question right the answer is the Aries extension is referencing configuration. In karaf/fuse for example the following:
>>>
>>> <cm:property-placeholder persistent-id="com.my.foo" update-strategy="reload">
>>>
>>> will load properties from etc/com.my.foo.cfg
>>>
>>> Installing that file is done either manually or by use of a features file.
>>>
>>> Whenever I've attempted to use the PID in more than one bundle it has failed and I don't think it is permitted. That's a problem I think and something that should be fixed through some other configuration management mechanism. Making microservices that might share common properties, for example, becomes problematic in that regard and I've resorted to using my own OSGi services to overcome that problem.
>>>
>>> Brad
>>>
>>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
>>> Ok, so after a brief review the cm schema is an Aries extension and it doesn't appear to support the location binding.
>>>
>>> However, it's unclear to me whether this extension is creating the configuration or merely referencing one from outside.
>>>
>>> Any Aries gurus can answer that?
>>>
>>> - Ray
>>>
>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>>> I’m not really familiar with blueprint cm but I’d expect that to indicate which pid to use to fetch the config from config admin and in the ... how to map configuration propertiething blueprint substitution knows about. Is that really instructions to create a new configuration and populate it with data (what a management agent does)?
>>>
>>> david jencks
>>>
>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
>>>>
>>>> David, I agree with everything you've said, however this looks like blueprint being the agent here:
>>>>
>>>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>>>> ...
>>>> </cm:property-placeholder>
>>>>
>>>> - Ray
>>>>
>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>>>> No, blueprint cm shouldn’t really know about the multi-location. The management agent that is creating the configuration should be setting the bundle location to the multi-location ”?”.
>>>>
>>>> david jencks
>>>>
>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>>>>
>>>>> I see and would it possible to configure which method is invoked from Blueprint?
>>>>>
>>>>> This is how I do it:
>>>>>
>>>>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>>>>> ...
>>>>> </cm:property-placeholder>
>>>>>
>>>>> is there perhaps some blueprint property where I can tune the second argument in the createFactoryConfiguration?
>>>>>
>>>>> Because it looks like the fact of using config admin through blueprint binds the PID to the first bundle using it
>>>>>
>>>>>
>>>>> best
>>>>> Pablo
>>>>>
>>>>>
>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>> As long as configurations are not bound to a bundle they can be used by any bundle.
>>>>>>
>>>>>> The exception clearly shows that the configuration is bound to a bundle.
>>>>>>
>>>>>> Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>>>>>
>>>>>>
>>>>>> HTH,
>>>>>> - Ray
>>>>>>
>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>>>> I don't think that's possible.
>>>>>>
>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>>>>> Hello All,
>>>>>>
>>>>>> Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
>>>>>>
>>>>>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm <http://org.osgi.service.cm/>.ManagedService, id=214, bundle=86/initial@reference:file:../plugin-1/ <mailto:bundle=86/initial@reference:file:../plugin-1/>]: No visibility to configuration bound to initial@reference:file:../plugin-2/ <mailto:initial@reference:file:../plugin-2/>
>>>>>>
>>>>>>
>>>>>> I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959 <https://issues.jboss.org/browse/ENTESB-3959>
>>>>>>
>>>>>>
>>>>>> However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
>>>>>>
>>>>>>
>>>>>> As a workaround I can make a config file per bundle that needs it....
>>>>>>
>>>>>> As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
>>>>>>
>>>>>> ID|State |Level|Name
>>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>> 67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
>>>>>> 147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
>>>>>>
>>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>>>> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
>>>>>> 148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
>>>>>>
>>>>>> 0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>
>>>>>>
>>>>>> --
>>>>>> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
>>>>>>
>>>>>> Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>>
>>>
>>>
>>>
>>> --
>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>>
>>>
>>
>>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Johan Edstrom <se...@gmail.com>.
It is in here; https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html <https://osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationAdmin.html>
A bundle is in aries bound to the pid. So it is actually working as expected, bit of
a hassle since spring-dm allowed it.
And yes selling DS into “regular" organizations is about as easy as selling snow in Alaska.
/je
> On Jul 7, 2016, at 12:00 PM, Brad Johnson <br...@mediadriver.com> wrote:
>
> David,
>
> You live in a very different world than I do. In all the consulting I do with Fuse/karaf blueprint is used almost exclusively. I understand DS and its uses but also its limits and overhead. It's like telling me one should only use Camel Java DSL. That may be one's perspective but that isn't everyone's.
>
> Brad
>
> On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
> IMNSHO blueprint is only really plausible if you have a large amount of Spring based code and you need to convert it to be sort of osgi-compatible really quickly without understanding osgi or the code. Otherwise taking the time to understand DS and use it is much more satisfactory. DS provides this configuration override ability with support for multiple pids, although only one of the pids can turn out to be a factory configuration. There’s no obvious way of correlating factory configurations, so this restriction makes some sense.
>
> I don’t think there really are any blueprint folks. The cm stuff, while obviously required to make the spec remotely plausible, hasn’t made it into the spec in the many many years it’s been sitting around.
>
> david jencks
>
>> On Jul 7, 2016, at 10:41 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>
>> If I were to sit down with the blueprint folks today to create a wish list one thing I'd like to see is for an ability to have a configuration hierarchy specified with parent/child relationships much like one has in Maven. Have a base configuration file and be able to have another cfg file specify that one as its parent. Override properties or add them to the child. When the configuration admin fires up it would read up the chain and construct the properties.
>>
>> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>> Ray,
>>
>> If I understand your question right the answer is the Aries extension is referencing configuration. In karaf/fuse for example the following:
>>
>> <cm:property-placeholder persistent-id="com.my.foo" update-strategy="reload">
>>
>> will load properties from etc/com.my.foo.cfg
>>
>> Installing that file is done either manually or by use of a features file.
>>
>> Whenever I've attempted to use the PID in more than one bundle it has failed and I don't think it is permitted. That's a problem I think and something that should be fixed through some other configuration management mechanism. Making microservices that might share common properties, for example, becomes problematic in that regard and I've resorted to using my own OSGi services to overcome that problem.
>>
>> Brad
>>
>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
>> Ok, so after a brief review the cm schema is an Aries extension and it doesn't appear to support the location binding.
>>
>> However, it's unclear to me whether this extension is creating the configuration or merely referencing one from outside.
>>
>> Any Aries gurus can answer that?
>>
>> - Ray
>>
>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>> I’m not really familiar with blueprint cm but I’d expect that to indicate which pid to use to fetch the config from config admin and in the ... how to map configuration propertiething blueprint substitution knows about. Is that really instructions to create a new configuration and populate it with data (what a management agent does)?
>>
>> david jencks
>>
>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
>>>
>>> David, I agree with everything you've said, however this looks like blueprint being the agent here:
>>>
>>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>>> ...
>>> </cm:property-placeholder>
>>>
>>> - Ray
>>>
>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>>> No, blueprint cm shouldn’t really know about the multi-location. The management agent that is creating the configuration should be setting the bundle location to the multi-location ”?”.
>>>
>>> david jencks
>>>
>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>>>
>>>> I see and would it possible to configure which method is invoked from Blueprint?
>>>>
>>>> This is how I do it:
>>>>
>>>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>>>> ...
>>>> </cm:property-placeholder>
>>>>
>>>> is there perhaps some blueprint property where I can tune the second argument in the createFactoryConfiguration?
>>>>
>>>> Because it looks like the fact of using config admin through blueprint binds the PID to the first bundle using it
>>>>
>>>>
>>>> best
>>>> Pablo
>>>>
>>>>
>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>> As long as configurations are not bound to a bundle they can be used by any bundle.
>>>>>
>>>>> The exception clearly shows that the configuration is bound to a bundle.
>>>>>
>>>>> Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>>>>
>>>>>
>>>>> HTH,
>>>>> - Ray
>>>>>
>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>>> I don't think that's possible.
>>>>>
>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>>>> Hello All,
>>>>>
>>>>> Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
>>>>>
>>>>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm <http://org.osgi.service.cm/>.ManagedService, id=214,bundle=86/initial@reference:file:../plugin-1/ <mailto:bundle=86/initial@reference:file:../plugin-1/>]: No visibility to configuration bound to initial@reference:file:../plugin-2/ <mailto:initial@reference:file:../plugin-2/>
>>>>>
>>>>>
>>>>> I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959 <https://issues.jboss.org/browse/ENTESB-3959>
>>>>>
>>>>>
>>>>> However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
>>>>>
>>>>>
>>>>> As a workaround I can make a config file per bundle that needs it....
>>>>>
>>>>> As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
>>>>>
>>>>> ID|State |Level|Name
>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>> 67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
>>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
>>>>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
>>>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
>>>>> 147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
>>>>>
>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>>> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
>>>>> 148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
>>>>>
>>>>> 0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>
>>>>>
>>>>> --
>>>>> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
>>>>>
>>>>> Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>
>>
>>
>>
>> --
>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>
>>
>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
David,
You live in a very different world than I do. In all the consulting I do
with Fuse/karaf blueprint is used almost exclusively. I understand DS and
its uses but also its limits and overhead. It's like telling me one should
only use Camel Java DSL. That may be one's perspective but that isn't
everyone's.
Brad
On Thu, Jul 7, 2016 at 12:53 PM, David Jencks <da...@yahoo.com>
wrote:
> IMNSHO blueprint is only really plausible if you have a large amount of
> Spring based code and you need to convert it to be sort of osgi-compatible
> really quickly without understanding osgi or the code. Otherwise taking
> the time to understand DS and use it is much more satisfactory. DS
> provides this configuration override ability with support for multiple
> pids, although only one of the pids can turn out to be a factory
> configuration. There’s no obvious way of correlating factory
> configurations, so this restriction makes some sense.
>
> I don’t think there really are any blueprint folks. The cm stuff, while
> obviously required to make the spec remotely plausible, hasn’t made it into
> the spec in the many many years it’s been sitting around.
>
> david jencks
>
> On Jul 7, 2016, at 10:41 AM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
> If I were to sit down with the blueprint folks today to create a wish list
> one thing I'd like to see is for an ability to have a configuration
> hierarchy specified with parent/child relationships much like one has in
> Maven. Have a base configuration file and be able to have another cfg file
> specify that one as its parent. Override properties or add them to the
> child. When the configuration admin fires up it would read up the chain
> and construct the properties.
>
> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <
> brad.johnson@mediadriver.com> wrote:
>
>> Ray,
>>
>> If I understand your question right the answer is the Aries extension is
>> referencing configuration. In karaf/fuse for example the following:
>>
>> <cm:property-placeholder persistent-id="com.my.foo"
>> update-strategy="reload">
>>
>> will load properties from etc/com.my.foo.cfg
>>
>> Installing that file is done either manually or by use of a features file.
>>
>> Whenever I've attempted to use the PID in more than one bundle it has
>> failed and I don't think it is permitted. That's a problem I think and
>> something that should be fixed through some other configuration management
>> mechanism. Making microservices that might share common properties, for
>> example, becomes problematic in that regard and I've resorted to using my
>> own OSGi services to overcome that problem.
>>
>> Brad
>>
>> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <ra...@liferay.com>
>> wrote:
>>
>>> Ok, so after a brief review the cm schema is an Aries extension and it
>>> doesn't appear to support the location binding.
>>>
>>> However, it's unclear to me whether this extension is creating the
>>> configuration or merely referencing one from outside.
>>>
>>> Any Aries gurus can answer that?
>>>
>>> - Ray
>>>
>>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <da...@yahoo.com>
>>> wrote:
>>>
>>>> I’m not really familiar with blueprint cm but I’d expect that to
>>>> indicate which pid to use to fetch the config from config admin and in the
>>>> ... how to map configuration propertiething blueprint substitution knows
>>>> about. Is that really instructions to create a new configuration and
>>>> populate it with data (what a management agent does)?
>>>>
>>>> david jencks
>>>>
>>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com>
>>>> wrote:
>>>>
>>>> David, I agree with everything you've said, however this looks like
>>>> blueprint being the agent here:
>>>>
>>>> <cm:property-placeholder persistent-id="my.id"
>>>> update-strategy="reload">
>>>> ...
>>>> </cm:property-placeholder>
>>>>
>>>> - Ray
>>>>
>>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <da...@yahoo.com>
>>>> wrote:
>>>>
>>>>> No, blueprint cm shouldn’t really know about the multi-location. The
>>>>> management agent that is creating the configuration should be setting the
>>>>> bundle location to the multi-location ”?”.
>>>>>
>>>>> david jencks
>>>>>
>>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
>>>>> wrote:
>>>>>
>>>>> I see and would it possible to configure which method is invoked from
>>>>> Blueprint?
>>>>>
>>>>> This is how I do it:
>>>>>
>>>>> <cm:property-placeholder persistent-id="my.id"
>>>>> update-strategy="reload">
>>>>> ...
>>>>> </cm:property-placeholder>
>>>>>
>>>>> is there perhaps some blueprint property where I can tune the second
>>>>> argument in the createFactoryConfiguration?
>>>>>
>>>>> Because it looks like the fact of using config admin through blueprint
>>>>> binds the PID to the first bundle using it
>>>>>
>>>>>
>>>>> best
>>>>> Pablo
>>>>>
>>>>>
>>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>>
>>>>> As long as configurations are not bound to a bundle they can be used
>>>>> by any bundle.
>>>>>
>>>>> The exception clearly shows that the configuration is bound to a
>>>>> bundle.
>>>>>
>>>>> Creating an unbound configuration requires passing a "?" as the second
>>>>> arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>>>>
>>>>>
>>>>> HTH,
>>>>> - Ray
>>>>>
>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>>> brad.johnson@mediadriver.com> wrote:
>>>>>
>>>>>> I don't think that's possible.
>>>>>>
>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>>
>>>>>>> Hello All,
>>>>>>>
>>>>>>> Is it possible to use same config file from multiple
>>>>>>> bundles while using Config Admin with blueprint Blueprint? Because, I can't
>>>>>>> manage to do that, I get the following error:
>>>>>>>
>>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No visibility to
>>>>>>> configuration bound to initial@reference:file:../plugin-2/
>>>>>>>
>>>>>>>
>>>>>>> I saw in this jira a bug opened:
>>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>>
>>>>>>>
>>>>>>> However, I fear that this is a problem in the aries blueprint
>>>>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>>> basically using blueprint:cm
>>>>>>>
>>>>>>>
>>>>>>> As a workaround I can make a config file per bundle that needs it....
>>>>>>>
>>>>>>> As follows the versions and bundles that I'm using related to the
>>>>>>> container (Running on top of Equinox 3.11):
>>>>>>>
>>>>>>> ID|State |Level|Name
>>>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>>>>>> DynamicMBean services (1.1.5)|1.1.5
>>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager
>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo
>>>>>>> Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
>>>>>>> Fragment Bundle (1.0.0)|1.0.0
>>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>>>>> (1.0.4)|1.0.4
>>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>>> 67|Active | 3|Aries Remote Service Admin Service Provider
>>>>>>> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>>> (1.1.1)|1.1.1
>>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy
>>>>>>> Runtimes (1.0.0)|1.0.0
>>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>>>>> 89|Active | 2|Apache Aries Transaction Manager
>>>>>>> (1.3.0)|1.3.0
>>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config
>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>>>>> (1.0.1)|1.0.1
>>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>>> (2.1.0)|2.1.0
>>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>>>>>> (1.0.1)|1.0.1
>>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery
>>>>>>> Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local
>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
>>>>>>> (1.0.8)|1.0.8
>>>>>>> 147|Active | 2|Aries JPA Container blueprint integration
>>>>>>> for Aries blueprint (1.0.4)|1.0.4
>>>>>>>
>>>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>>>>> 104|Active | 4|Apache Felix Coordinator Service
>>>>>>> (1.0.2)|1.0.2
>>>>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>>>> (1.2.8)|1.2.8
>>>>>>> 148|Active | 4|Apache Felix Configuration Admin Service
>>>>>>> (1.8.8)|1.8.8
>>>>>>>
>>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> WARNING: Computer viruses can be transmitted via email. The
>>>>>>> recipient should check this email and any attachments for the presence of
>>>>>>> viruses. The company accepts no liability for any damage caused by any
>>>>>>> virus transmitted by this email. E-mail transmission cannot be guaranteed
>>>>>>> to be secure or error-free as information could be intercepted, corrupted,
>>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>>
>>>>>>> Warning: Although the company has taken reasonable precautions to
>>>>>>> ensure no viruses are present in this email, the company cannot accept
>>>>>>> responsibility for any loss or damage arising from the use of this email or
>>>>>>> attachments.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>> (@rotty3000)
>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>>> (@Liferay)
>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>>> (@OSGiAlliance)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>> (@rotty3000)
>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>> (@Liferay)
>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>> (@OSGiAlliance)
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>> (@OSGiAlliance)
>>>
>>
>>
>
>
Re: blueprint:cm multiple bundle but same config file
Posted by David Jencks <da...@yahoo.com>.
IMNSHO blueprint is only really plausible if you have a large amount of Spring based code and you need to convert it to be sort of osgi-compatible really quickly without understanding osgi or the code. Otherwise taking the time to understand DS and use it is much more satisfactory. DS provides this configuration override ability with support for multiple pids, although only one of the pids can turn out to be a factory configuration. There’s no obvious way of correlating factory configurations, so this restriction makes some sense.
I don’t think there really are any blueprint folks. The cm stuff, while obviously required to make the spec remotely plausible, hasn’t made it into the spec in the many many years it’s been sitting around.
david jencks
> On Jul 7, 2016, at 10:41 AM, Brad Johnson <br...@mediadriver.com> wrote:
>
> If I were to sit down with the blueprint folks today to create a wish list one thing I'd like to see is for an ability to have a configuration hierarchy specified with parent/child relationships much like one has in Maven. Have a base configuration file and be able to have another cfg file specify that one as its parent. Override properties or add them to the child. When the configuration admin fires up it would read up the chain and construct the properties.
>
> On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
> Ray,
>
> If I understand your question right the answer is the Aries extension is referencing configuration. In karaf/fuse for example the following:
>
> <cm:property-placeholder persistent-id="com.my.foo" update-strategy="reload">
>
> will load properties from etc/com.my.foo.cfg
>
> Installing that file is done either manually or by use of a features file.
>
> Whenever I've attempted to use the PID in more than one bundle it has failed and I don't think it is permitted. That's a problem I think and something that should be fixed through some other configuration management mechanism. Making microservices that might share common properties, for example, becomes problematic in that regard and I've resorted to using my own OSGi services to overcome that problem.
>
> Brad
>
> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
> Ok, so after a brief review the cm schema is an Aries extension and it doesn't appear to support the location binding.
>
> However, it's unclear to me whether this extension is creating the configuration or merely referencing one from outside.
>
> Any Aries gurus can answer that?
>
> - Ray
>
> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
> I’m not really familiar with blueprint cm but I’d expect that to indicate which pid to use to fetch the config from config admin and in the ... how to map configuration propertiething blueprint substitution knows about. Is that really instructions to create a new configuration and populate it with data (what a management agent does)?
>
> david jencks
>
>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <raymond.auge@liferay.com <ma...@liferay.com>> wrote:
>>
>> David, I agree with everything you've said, however this looks like blueprint being the agent here:
>>
>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>> ...
>> </cm:property-placeholder>
>>
>> - Ray
>>
>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
>> No, blueprint cm shouldn’t really know about the multi-location. The management agent that is creating the configuration should be setting the bundle location to the multi-location ”?”.
>>
>> david jencks
>>
>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>>
>>> I see and would it possible to configure which method is invoked from Blueprint?
>>>
>>> This is how I do it:
>>>
>>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>>> ...
>>> </cm:property-placeholder>
>>>
>>> is there perhaps some blueprint property where I can tune the second argument in the createFactoryConfiguration?
>>>
>>> Because it looks like the fact of using config admin through blueprint binds the PID to the first bundle using it
>>>
>>>
>>> best
>>> Pablo
>>>
>>>
>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>> As long as configurations are not bound to a bundle they can be used by any bundle.
>>>>
>>>> The exception clearly shows that the configuration is bound to a bundle.
>>>>
>>>> Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>>>
>>>>
>>>> HTH,
>>>> - Ray
>>>>
>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>>> I don't think that's possible.
>>>>
>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>>> Hello All,
>>>>
>>>> Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
>>>>
>>>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm <http://org.osgi.service.cm/>.ManagedService, id=214, bundle=86/initial@reference:file:../plugin-1/ <mailto:bundle=86/initial@reference:file:../plugin-1/>]: No visibility to configuration bound to initial@reference:file:../plugin-2/ <mailto:initial@reference:file:../plugin-2/>
>>>>
>>>>
>>>> I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959 <https://issues.jboss.org/browse/ENTESB-3959>
>>>>
>>>>
>>>> However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
>>>>
>>>>
>>>> As a workaround I can make a config file per bundle that needs it....
>>>>
>>>> As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
>>>>
>>>> ID|State |Level|Name
>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>> 67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
>>>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
>>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
>>>> 147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
>>>>
>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
>>>> 148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
>>>>
>>>> 0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>
>>>>
>>>> --
>>>> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
>>>>
>>>> Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>>
>>
>>
>>
>>
>> --
>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>
>
>
>
> --
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
If I were to sit down with the blueprint folks today to create a wish list
one thing I'd like to see is for an ability to have a configuration
hierarchy specified with parent/child relationships much like one has in
Maven. Have a base configuration file and be able to have another cfg file
specify that one as its parent. Override properties or add them to the
child. When the configuration admin fires up it would read up the chain
and construct the properties.
On Thu, Jul 7, 2016 at 12:37 PM, Brad Johnson <br...@mediadriver.com>
wrote:
> Ray,
>
> If I understand your question right the answer is the Aries extension is
> referencing configuration. In karaf/fuse for example the following:
>
> <cm:property-placeholder persistent-id="com.my.foo"
> update-strategy="reload">
>
> will load properties from etc/com.my.foo.cfg
>
> Installing that file is done either manually or by use of a features file.
>
> Whenever I've attempted to use the PID in more than one bundle it has
> failed and I don't think it is permitted. That's a problem I think and
> something that should be fixed through some other configuration management
> mechanism. Making microservices that might share common properties, for
> example, becomes problematic in that regard and I've resorted to using my
> own OSGi services to overcome that problem.
>
> Brad
>
> On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <ra...@liferay.com>
> wrote:
>
>> Ok, so after a brief review the cm schema is an Aries extension and it
>> doesn't appear to support the location binding.
>>
>> However, it's unclear to me whether this extension is creating the
>> configuration or merely referencing one from outside.
>>
>> Any Aries gurus can answer that?
>>
>> - Ray
>>
>> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <da...@yahoo.com>
>> wrote:
>>
>>> I’m not really familiar with blueprint cm but I’d expect that to
>>> indicate which pid to use to fetch the config from config admin and in the
>>> ... how to map configuration propertiething blueprint substitution knows
>>> about. Is that really instructions to create a new configuration and
>>> populate it with data (what a management agent does)?
>>>
>>> david jencks
>>>
>>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com>
>>> wrote:
>>>
>>> David, I agree with everything you've said, however this looks like
>>> blueprint being the agent here:
>>>
>>> <cm:property-placeholder persistent-id="my.id" update-strategy="reload">
>>> ...
>>> </cm:property-placeholder>
>>>
>>> - Ray
>>>
>>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <da...@yahoo.com>
>>> wrote:
>>>
>>>> No, blueprint cm shouldn’t really know about the multi-location. The
>>>> management agent that is creating the configuration should be setting the
>>>> bundle location to the multi-location ”?”.
>>>>
>>>> david jencks
>>>>
>>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
>>>> wrote:
>>>>
>>>> I see and would it possible to configure which method is invoked from
>>>> Blueprint?
>>>>
>>>> This is how I do it:
>>>>
>>>> <cm:property-placeholder persistent-id="my.id"
>>>> update-strategy="reload">
>>>> ...
>>>> </cm:property-placeholder>
>>>>
>>>> is there perhaps some blueprint property where I can tune the second
>>>> argument in the createFactoryConfiguration?
>>>>
>>>> Because it looks like the fact of using config admin through blueprint
>>>> binds the PID to the first bundle using it
>>>>
>>>>
>>>> best
>>>> Pablo
>>>>
>>>>
>>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>>
>>>> As long as configurations are not bound to a bundle they can be used by
>>>> any bundle.
>>>>
>>>> The exception clearly shows that the configuration is bound to a
>>>> bundle.
>>>>
>>>> Creating an unbound configuration requires passing a "?" as the second
>>>> arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>>>
>>>>
>>>> HTH,
>>>> - Ray
>>>>
>>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>>> brad.johnson@mediadriver.com> wrote:
>>>>
>>>>> I don't think that's possible.
>>>>>
>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>> pablo.gomez@faw.jku.at> wrote:
>>>>>
>>>>>> Hello All,
>>>>>>
>>>>>> Is it possible to use same config file from multiple
>>>>>> bundles while using Config Admin with blueprint Blueprint? Because, I can't
>>>>>> manage to do that, I get the following error:
>>>>>>
>>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>>> bundle=86/initial@reference:file:../plugin-1/]: No visibility to
>>>>>> configuration bound to initial@reference:file:../plugin-2/
>>>>>>
>>>>>>
>>>>>> I saw in this jira a bug opened:
>>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>>
>>>>>>
>>>>>> However, I fear that this is a problem in the aries blueprint
>>>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>>> basically using blueprint:cm
>>>>>>
>>>>>>
>>>>>> As a workaround I can make a config file per bundle that needs it....
>>>>>>
>>>>>> As follows the versions and bundles that I'm using related to the
>>>>>> container (Running on top of Equinox 3.11):
>>>>>>
>>>>>> ID|State |Level|Name
>>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>>>>> DynamicMBean services (1.1.5)|1.1.5
>>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager
>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo
>>>>>> Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
>>>>>> Fragment Bundle (1.0.0)|1.0.0
>>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>>>> (1.0.4)|1.0.4
>>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>>> 67|Active | 3|Aries Remote Service Admin Service Provider
>>>>>> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>>> (1.1.1)|1.1.1
>>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes
>>>>>> (1.0.0)|1.0.0
>>>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config
>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>>>> (1.0.1)|1.0.1
>>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>>> (2.1.0)|2.1.0
>>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>>>>> (1.0.1)|1.0.1
>>>>>> 132|Active | 3|Aries Remote Service Admin Discovery
>>>>>> Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local
>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
>>>>>> (1.0.8)|1.0.8
>>>>>> 147|Active | 2|Aries JPA Container blueprint integration for
>>>>>> Aries blueprint (1.0.4)|1.0.4
>>>>>>
>>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>>> (1.2.8)|1.2.8
>>>>>> 148|Active | 4|Apache Felix Configuration Admin Service
>>>>>> (1.8.8)|1.8.8
>>>>>>
>>>>>> 0|Active | 0|OSGi System Bundle
>>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>>
>>>>>>
>>>>>> --
>>>>>> WARNING: Computer viruses can be transmitted via email. The recipient
>>>>>> should check this email and any attachments for the presence of viruses.
>>>>>> The company accepts no liability for any damage caused by any virus
>>>>>> transmitted by this email. E-mail transmission cannot be guaranteed to be
>>>>>> secure or error-free as information could be intercepted, corrupted, lost,
>>>>>> destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>>> therefore does not accept liability for any errors or omissions in the
>>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>>
>>>>>> Warning: Although the company has taken reasonable precautions to
>>>>>> ensure no viruses are present in this email, the company cannot accept
>>>>>> responsibility for any loss or damage arising from the use of this email or
>>>>>> attachments.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>> (@rotty3000)
>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>>> (@Liferay)
>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>>> (@OSGiAlliance)
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>> (@OSGiAlliance)
>>>
>>>
>>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>> (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>> (@OSGiAlliance)
>>
>
>
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
Ray,
If I understand your question right the answer is the Aries extension is
referencing configuration. In karaf/fuse for example the following:
<cm:property-placeholder persistent-id="com.my.foo"
update-strategy="reload">
will load properties from etc/com.my.foo.cfg
Installing that file is done either manually or by use of a features file.
Whenever I've attempted to use the PID in more than one bundle it has
failed and I don't think it is permitted. That's a problem I think and
something that should be fixed through some other configuration management
mechanism. Making microservices that might share common properties, for
example, becomes problematic in that regard and I've resorted to using my
own OSGi services to overcome that problem.
Brad
On Thu, Jul 7, 2016 at 10:46 AM, Raymond Auge <ra...@liferay.com>
wrote:
> Ok, so after a brief review the cm schema is an Aries extension and it
> doesn't appear to support the location binding.
>
> However, it's unclear to me whether this extension is creating the
> configuration or merely referencing one from outside.
>
> Any Aries gurus can answer that?
>
> - Ray
>
> On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <da...@yahoo.com>
> wrote:
>
>> I’m not really familiar with blueprint cm but I’d expect that to indicate
>> which pid to use to fetch the config from config admin and in the ... how
>> to map configuration propertiething blueprint substitution knows about. Is
>> that really instructions to create a new configuration and populate it with
>> data (what a management agent does)?
>>
>> david jencks
>>
>> On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com>
>> wrote:
>>
>> David, I agree with everything you've said, however this looks like
>> blueprint being the agent here:
>>
>> <cm:property-placeholder persistent-id="my.id" update-strategy="reload">
>> ...
>> </cm:property-placeholder>
>>
>> - Ray
>>
>> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <da...@yahoo.com>
>> wrote:
>>
>>> No, blueprint cm shouldn’t really know about the multi-location. The
>>> management agent that is creating the configuration should be setting the
>>> bundle location to the multi-location ”?”.
>>>
>>> david jencks
>>>
>>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
>>> wrote:
>>>
>>> I see and would it possible to configure which method is invoked from
>>> Blueprint?
>>>
>>> This is how I do it:
>>>
>>> <cm:property-placeholder persistent-id="my.id" update-strategy="reload">
>>> ...
>>> </cm:property-placeholder>
>>>
>>> is there perhaps some blueprint property where I can tune the second
>>> argument in the createFactoryConfiguration?
>>>
>>> Because it looks like the fact of using config admin through blueprint
>>> binds the PID to the first bundle using it
>>>
>>>
>>> best
>>> Pablo
>>>
>>>
>>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>>
>>> As long as configurations are not bound to a bundle they can be used by
>>> any bundle.
>>>
>>> The exception clearly shows that the configuration is bound to a bundle.
>>>
>>> Creating an unbound configuration requires passing a "?" as the second
>>> arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>>
>>>
>>> HTH,
>>> - Ray
>>>
>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>>> brad.johnson@mediadriver.com> wrote:
>>>
>>>> I don't think that's possible.
>>>>
>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>> pablo.gomez@faw.jku.at> wrote:
>>>>
>>>>> Hello All,
>>>>>
>>>>> Is it possible to use same config file from multiple bundles
>>>>> while using Config Admin with blueprint Blueprint? Because, I can't manage
>>>>> to do that, I get the following error:
>>>>>
>>>>> MESSAGE Cannot use configuration test.mybundle for [
>>>>> org.osgi.service.cm.ManagedService, id=214,
>>>>> bundle=86/initial@reference:file:../plugin-1/]: No visibility to
>>>>> configuration bound to initial@reference:file:../plugin-2/
>>>>>
>>>>>
>>>>> I saw in this jira a bug opened:
>>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>>
>>>>>
>>>>> However, I fear that this is a problem in the aries blueprint
>>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>>> basically using blueprint:cm
>>>>>
>>>>>
>>>>> As a workaround I can make a config file per bundle that needs it....
>>>>>
>>>>> As follows the versions and bundles that I'm using related to the
>>>>> container (Running on top of Equinox 3.11):
>>>>>
>>>>> ID|State |Level|Name
>>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>>>> DynamicMBean services (1.1.5)|1.1.5
>>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager
>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo
>>>>> Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
>>>>> Fragment Bundle (1.0.0)|1.0.0
>>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>>> (1.0.4)|1.0.4
>>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>>> 67|Active | 3|Aries Remote Service Admin Service Provider
>>>>> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 71|Active | 2|Apache Aries Transaction Blueprint
>>>>> (1.1.1)|1.1.1
>>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes
>>>>> (1.0.0)|1.0.0
>>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config
>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>>> (1.0.1)|1.0.1
>>>>> 120|Active | 2|Apache Aries Transaction Blueprint
>>>>> (2.1.0)|2.1.0
>>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>>>> (1.0.1)|1.0.1
>>>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper
>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local
>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
>>>>> (1.0.8)|1.0.8
>>>>> 147|Active | 2|Aries JPA Container blueprint integration for
>>>>> Aries blueprint (1.0.4)|1.0.4
>>>>>
>>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>>> 114|Active | 4|Apache Felix Web Management Console
>>>>> (1.2.8)|1.2.8
>>>>> 148|Active | 4|Apache Felix Configuration Admin Service
>>>>> (1.8.8)|1.8.8
>>>>>
>>>>> 0|Active | 0|OSGi System Bundle
>>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>>
>>>>>
>>>>> --
>>>>> WARNING: Computer viruses can be transmitted via email. The recipient
>>>>> should check this email and any attachments for the presence of viruses.
>>>>> The company accepts no liability for any damage caused by any virus
>>>>> transmitted by this email. E-mail transmission cannot be guaranteed to be
>>>>> secure or error-free as information could be intercepted, corrupted, lost,
>>>>> destroyed, arrive late or incomplete, or contain viruses. The sender
>>>>> therefore does not accept liability for any errors or omissions in the
>>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>>
>>>>> Warning: Although the company has taken reasonable precautions to
>>>>> ensure no viruses are present in this email, the company cannot accept
>>>>> responsibility for any loss or damage arising from the use of this email or
>>>>> attachments.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>>> (@OSGiAlliance)
>>>
>>>
>>>
>>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>> (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>> (@OSGiAlliance)
>>
>>
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
Re: blueprint:cm multiple bundle but same config file
Posted by Raymond Auge <ra...@liferay.com>.
Ok, so after a brief review the cm schema is an Aries extension and it
doesn't appear to support the location binding.
However, it's unclear to me whether this extension is creating the
configuration or merely referencing one from outside.
Any Aries gurus can answer that?
- Ray
On Thu, Jul 7, 2016 at 11:29 AM, David Jencks <da...@yahoo.com>
wrote:
> I’m not really familiar with blueprint cm but I’d expect that to indicate
> which pid to use to fetch the config from config admin and in the ... how
> to map configuration propertiething blueprint substitution knows about. Is
> that really instructions to create a new configuration and populate it with
> data (what a management agent does)?
>
> david jencks
>
> On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com> wrote:
>
> David, I agree with everything you've said, however this looks like
> blueprint being the agent here:
>
> <cm:property-placeholder persistent-id="my.id" update-strategy="reload">
> ...
> </cm:property-placeholder>
>
> - Ray
>
> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <da...@yahoo.com>
> wrote:
>
>> No, blueprint cm shouldn’t really know about the multi-location. The
>> management agent that is creating the configuration should be setting the
>> bundle location to the multi-location ”?”.
>>
>> david jencks
>>
>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
>> wrote:
>>
>> I see and would it possible to configure which method is invoked from
>> Blueprint?
>>
>> This is how I do it:
>>
>> <cm:property-placeholder persistent-id="my.id" update-strategy="reload">
>> ...
>> </cm:property-placeholder>
>>
>> is there perhaps some blueprint property where I can tune the second
>> argument in the createFactoryConfiguration?
>>
>> Because it looks like the fact of using config admin through blueprint
>> binds the PID to the first bundle using it
>>
>>
>> best
>> Pablo
>>
>>
>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>
>> As long as configurations are not bound to a bundle they can be used by
>> any bundle.
>>
>> The exception clearly shows that the configuration is bound to a bundle.
>>
>> Creating an unbound configuration requires passing a "?" as the second
>> arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>
>>
>> HTH,
>> - Ray
>>
>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
>> brad.johnson@mediadriver.com> wrote:
>>
>>> I don't think that's possible.
>>>
>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>> pablo.gomez@faw.jku.at> wrote:
>>>
>>>> Hello All,
>>>>
>>>> Is it possible to use same config file from multiple bundles
>>>> while using Config Admin with blueprint Blueprint? Because, I can't manage
>>>> to do that, I get the following error:
>>>>
>>>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm.ManagedService,
>>>> id=214, bundle=86/initial@reference:file:../plugin-1/]: No visibility
>>>> to configuration bound to initial@reference:file:../plugin-2/
>>>>
>>>>
>>>> I saw in this jira a bug opened:
>>>> https://issues.jboss.org/browse/ENTESB-3959
>>>>
>>>>
>>>> However, I fear that this is a problem in the aries blueprint
>>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>>> container. Either that or I'm missing some blueprint configuration. I'm
>>>> basically using blueprint:cm
>>>>
>>>>
>>>> As a workaround I can make a config file per bundle that needs it....
>>>>
>>>> As follows the versions and bundles that I'm using related to the
>>>> container (Running on top of Equinox 3.11):
>>>>
>>>> ID|State |Level|Name
>>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>>> DynamicMBean services (1.1.5)|1.1.5
>>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>>> 13|Active | 3|Aries Remote Service Admin Topology Manager
>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo
>>>> Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
>>>> Fragment Bundle (1.0.0)|1.0.0
>>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>>> (1.0.4)|1.0.4
>>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>>> 67|Active | 3|Aries Remote Service Admin Service Provider
>>>> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes
>>>> (1.0.0)|1.0.0
>>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>>> 94|Active | 3|Aries Remote Service Admin Discovery Config
>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>>> (1.0.1)|1.0.1
>>>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>>> (1.0.1)|1.0.1
>>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper
>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 134|Active | 3|Aries Remote Service Admin Discovery Local
>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 138|Active | 3|Aries Remote Service Admin Core
>>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
>>>> (1.0.8)|1.0.8
>>>> 147|Active | 2|Aries JPA Container blueprint integration for
>>>> Aries blueprint (1.0.4)|1.0.4
>>>>
>>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>> 114|Active | 4|Apache Felix Web Management Console
>>>> (1.2.8)|1.2.8
>>>> 148|Active | 4|Apache Felix Configuration Admin Service
>>>> (1.8.8)|1.8.8
>>>>
>>>> 0|Active | 0|OSGi System Bundle
>>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>>
>>>>
>>>> --
>>>> WARNING: Computer viruses can be transmitted via email. The recipient
>>>> should check this email and any attachments for the presence of viruses.
>>>> The company accepts no liability for any damage caused by any virus
>>>> transmitted by this email. E-mail transmission cannot be guaranteed to be
>>>> secure or error-free as information could be intercepted, corrupted, lost,
>>>> destroyed, arrive late or incomplete, or contain viruses. The sender
>>>> therefore does not accept liability for any errors or omissions in the
>>>> contents of this message, which arise as a result of e-mail transmission.
>>>>
>>>> Warning: Although the company has taken reasonable precautions to
>>>> ensure no viruses are present in this email, the company cannot accept
>>>> responsibility for any loss or damage arising from the use of this email or
>>>> attachments.
>>>>
>>>
>>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>> (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
>> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
>> (@OSGiAlliance)
>>
>>
>>
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
> (@OSGiAlliance)
>
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: blueprint:cm multiple bundle but same config file
Posted by David Jencks <da...@yahoo.com>.
I’m not really familiar with blueprint cm but I’d expect that to indicate which pid to use to fetch the config from config admin and in the ... how to map configuration propertiething blueprint substitution knows about. Is that really instructions to create a new configuration and populate it with data (what a management agent does)?
david jencks
> On Jul 7, 2016, at 8:19 AM, Raymond Auge <ra...@liferay.com> wrote:
>
> David, I agree with everything you've said, however this looks like blueprint being the agent here:
>
> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
> ...
> </cm:property-placeholder>
>
> - Ray
>
> On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <david_jencks@yahoo.com <ma...@yahoo.com>> wrote:
> No, blueprint cm shouldn’t really know about the multi-location. The management agent that is creating the configuration should be setting the bundle location to the multi-location ”?”.
>
> david jencks
>
>> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>
>> I see and would it possible to configure which method is invoked from Blueprint?
>>
>> This is how I do it:
>>
>> <cm:property-placeholder persistent-id="my.id <http://my.id/>" update-strategy="reload">
>> ...
>> </cm:property-placeholder>
>>
>> is there perhaps some blueprint property where I can tune the second argument in the createFactoryConfiguration?
>>
>> Because it looks like the fact of using config admin through blueprint binds the PID to the first bundle using it
>>
>>
>> best
>> Pablo
>>
>>
>> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>>> As long as configurations are not bound to a bundle they can be used by any bundle.
>>>
>>> The exception clearly shows that the configuration is bound to a bundle.
>>>
>>> Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>>
>>>
>>> HTH,
>>> - Ray
>>>
>>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>>> I don't think that's possible.
>>>
>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>>> Hello All,
>>>
>>> Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
>>>
>>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm <http://org.osgi.service.cm/>.ManagedService, id=214, bundle=86/initial@reference:file:../plugin-1/ <mailto:bundle=86/initial@reference:file:../plugin-1/>]: No visibility to configuration bound to initial@reference:file:../plugin-2/ <mailto:initial@reference:file:../plugin-2/>
>>>
>>>
>>> I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959 <https://issues.jboss.org/browse/ENTESB-3959>
>>>
>>>
>>> However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
>>>
>>>
>>> As a workaround I can make a config file per bundle that needs it....
>>>
>>> As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
>>>
>>> ID|State |Level|Name
>>> 5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>> 13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>> 67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>> 94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
>>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
>>> 147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
>>>
>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
>>> 148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
>>>
>>> 0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>
>>>
>>> --
>>> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
>>>
>>> Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>>>
>>>
>>>
>>>
>>> --
>>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>
>
>
>
>
> --
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
Re: blueprint:cm multiple bundle but same config file
Posted by Raymond Auge <ra...@liferay.com>.
David, I agree with everything you've said, however this looks like
blueprint being the agent here:
<cm:property-placeholder persistent-id="my.id" update-strategy="reload">
...
</cm:property-placeholder>
- Ray
On Thu, Jul 7, 2016 at 11:18 AM, David Jencks <da...@yahoo.com>
wrote:
> No, blueprint cm shouldn’t really know about the multi-location. The
> management agent that is creating the configuration should be setting the
> bundle location to the multi-location ”?”.
>
> david jencks
>
> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
> wrote:
>
> I see and would it possible to configure which method is invoked from
> Blueprint?
>
> This is how I do it:
>
> <cm:property-placeholder persistent-id="my.id" update-strategy="reload">
> ...
> </cm:property-placeholder>
>
> is there perhaps some blueprint property where I can tune the second
> argument in the createFactoryConfiguration?
>
> Because it looks like the fact of using config admin through blueprint
> binds the PID to the first bundle using it
>
>
> best
> Pablo
>
>
> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>
> As long as configurations are not bound to a bundle they can be used by
> any bundle.
>
> The exception clearly shows that the configuration is bound to a bundle.
>
> Creating an unbound configuration requires passing a "?" as the second
> arguments to getConfiguration/createFactoryConfiguration methods of CM.
>
>
> HTH,
> - Ray
>
> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <
> brad.johnson@mediadriver.com> wrote:
>
>> I don't think that's possible.
>>
>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at
>> > wrote:
>>
>>> Hello All,
>>>
>>> Is it possible to use same config file from multiple bundles
>>> while using Config Admin with blueprint Blueprint? Because, I can't manage
>>> to do that, I get the following error:
>>>
>>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm.ManagedService,
>>> id=214, bundle=86/initial@reference:file:../plugin-1/]: No visibility
>>> to configuration bound to initial@reference:file:../plugin-2/
>>>
>>>
>>> I saw in this jira a bug opened:
>>> https://issues.jboss.org/browse/ENTESB-3959
>>>
>>>
>>> However, I fear that this is a problem in the aries blueprint
>>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>>> container. Either that or I'm missing some blueprint configuration. I'm
>>> basically using blueprint:cm
>>>
>>>
>>> As a workaround I can make a config file per bundle that needs it....
>>>
>>> As follows the versions and bundles that I'm using related to the
>>> container (Running on top of Equinox 3.11):
>>>
>>> ID|State |Level|Name
>>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>>> DynamicMBean services (1.1.5)|1.1.5
>>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>>> 13|Active | 3|Aries Remote Service Admin Topology Manager
>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo
>>> Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity
>>> Fragment Bundle (1.0.0)|1.0.0
>>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>>> 56|Active | 2|Aries JPA Container Managed Contexts
>>> (1.0.4)|1.0.4
>>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>>> 67|Active | 3|Aries Remote Service Admin Service Provider
>>> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes
>>> (1.0.0)|1.0.0
>>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>>> 94|Active | 3|Aries Remote Service Admin Discovery Config
>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 97|Active | 3|Aries Remote Service Admin provider TCP
>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 110|Active | 2|Apache Aries Blueprint Annotation API
>>> (1.0.1)|1.0.1
>>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>>> (1.0.1)|1.0.1
>>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper
>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 134|Active | 3|Aries Remote Service Admin Discovery Local
>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 138|Active | 3|Aries Remote Service Admin Core
>>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
>>> (1.0.8)|1.0.8
>>> 147|Active | 2|Aries JPA Container blueprint integration for
>>> Aries blueprint (1.0.4)|1.0.4
>>>
>>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
>>> 148|Active | 4|Apache Felix Configuration Admin Service
>>> (1.8.8)|1.8.8
>>>
>>> 0|Active | 0|OSGi System Bundle
>>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>>
>>>
>>> --
>>> WARNING: Computer viruses can be transmitted via email. The recipient
>>> should check this email and any attachments for the presence of viruses.
>>> The company accepts no liability for any damage caused by any virus
>>> transmitted by this email. E-mail transmission cannot be guaranteed to be
>>> secure or error-free as information could be intercepted, corrupted, lost,
>>> destroyed, arrive late or incomplete, or contain viruses. The sender
>>> therefore does not accept liability for any errors or omissions in the
>>> contents of this message, which arise as a result of e-mail transmission.
>>>
>>> Warning: Although the company has taken reasonable precautions to ensure
>>> no viruses are present in this email, the company cannot accept
>>> responsibility for any loss or damage arising from the use of this email or
>>> attachments.
>>>
>>
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/>
> (@OSGiAlliance)
>
>
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: blueprint:cm multiple bundle but same config file
Posted by David Jencks <da...@yahoo.com>.
No, blueprint cm shouldn’t really know about the multi-location. The management agent that is creating the configuration should be setting the bundle location to the multi-location ”?”.
david jencks
> On Jul 7, 2016, at 8:12 AM, Pablo Gómez Pérez <pa...@faw.jku.at> wrote:
>
> I see and would it possible to configure which method is invoked from Blueprint?
>
> This is how I do it:
>
> <cm:property-placeholder persistent-id="my.id" update-strategy="reload">
> ...
> </cm:property-placeholder>
>
> is there perhaps some blueprint property where I can tune the second argument in the createFactoryConfiguration?
>
> Because it looks like the fact of using config admin through blueprint binds the PID to the first bundle using it
>
>
> best
> Pablo
>
>
> On 07/07/2016 4:41 PM, Raymond Auge wrote:
>> As long as configurations are not bound to a bundle they can be used by any bundle.
>>
>> The exception clearly shows that the configuration is bound to a bundle.
>>
>> Creating an unbound configuration requires passing a "?" as the second arguments to getConfiguration/createFactoryConfiguration methods of CM.
>>
>>
>> HTH,
>> - Ray
>>
>> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <brad.johnson@mediadriver.com <ma...@mediadriver.com>> wrote:
>> I don't think that's possible.
>>
>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>> Hello All,
>>
>> Is it possible to use same config file from multiple bundles while using Config Admin with blueprint Blueprint? Because, I can't manage to do that, I get the following error:
>>
>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm <http://org.osgi.service.cm/>.ManagedService, id=214, bundle=86/initial@reference:file:../plugin-1/ <mailto:bundle=86/initial@reference:file:../plugin-1/>]: No visibility to configuration bound toinitial@reference:file:../plugin-2/ <mailto:initial@reference:file:../plugin-2/>
>>
>>
>> I saw in this jira a bug opened: https://issues.jboss.org/browse/ENTESB-3959 <https://issues.jboss.org/browse/ENTESB-3959>
>>
>>
>> However, I fear that this is a problem in the aries blueprint implementation as I'm not using KARAF nor FUSE, just a plain osgi container. Either that or I'm missing some blueprint configuration. I'm basically using blueprint:cm
>>
>>
>> As a workaround I can make a config file per bundle that needs it....
>>
>> As follows the versions and bundles that I'm using related to the container (Running on top of Equinox 3.11):
>>
>> ID|State |Level|Name
>> 5|Active | 2|Apache Aries Whiteboard support for JMX DynamicMBean services (1.1.5)|1.1.5
>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>> 13|Active | 3|Aries Remote Service Admin Topology Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0)|1.0.0
>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>> 67|Active | 3|Aries Remote Service Admin Service Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes (1.0.0)|1.0.0
>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>> 94|Active | 3|Aries Remote Service Admin Discovery Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 97|Active | 3|Aries Remote Service Admin provider TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>> 130|Active | 2|Apache Aries Blueprint Annotation Impl (1.0.1)|1.0.1
>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 134|Active | 3|Aries Remote Service Admin Discovery Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 138|Active | 3|Aries Remote Service Admin Core (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle (1.0.8)|1.0.8
>> 147|Active | 2|Aries JPA Container blueprint integration for Aries blueprint (1.0.4)|1.0.4
>>
>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
>> 148|Active | 4|Apache Felix Configuration Admin Service (1.8.8)|1.8.8
>>
>> 0|Active | 0|OSGi System Bundle (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>
>>
>> --
>> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
>>
>> Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
>>
>>
>>
>>
>> --
>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>
Re: blueprint:cm multiple bundle but same config file
Posted by Pablo Gómez Pérez <pa...@faw.jku.at>.
I see and would it possible to configure which method is invoked from
Blueprint?
This is how I do it:
<cm:property-placeholder persistent-id="my.id" update-strategy="reload">
...
</cm:property-placeholder>
is there perhaps some blueprint property where I can tune the second
argument in the createFactoryConfiguration?
Because it looks like the fact of using config admin through blueprint
binds the PID to the first bundle using it
best
Pablo
On 07/07/2016 4:41 PM, Raymond Auge wrote:
> As long as configurations are not bound to a bundle they can be used
> by any bundle.
>
> The exception clearly shows that the configuration is bound to a bundle.
>
> Creating an unbound configuration requires passing a "?" as the second
> arguments to getConfiguration/createFactoryConfiguration methods of CM.
>
>
> HTH,
> - Ray
>
> On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson
> <brad.johnson@mediadriver.com <ma...@mediadriver.com>>
> wrote:
>
> I don't think that's possible.
>
> On Thu, Jul 7, 2016 at 8:51 AM, Pablo G�mez P�rez
> <pablo.gomez@faw.jku.at <ma...@faw.jku.at>> wrote:
>
> Hello All,
>
> Is it possible to use same config file from multiple
> bundles while using Config Admin with blueprint Blueprint?
> Because, I can't manage to do that, I get the following error:
>
> MESSAGE Cannot use configuration test.mybundle for
> [org.osgi.service.cm
> <http://org.osgi.service.cm>.ManagedService, id=214,
> bundle=86/initial@reference:file:../plugin-1/]: No visibility
> to configuration bound to initial@reference:file:../plugin-2/
>
>
> I saw in this jira a bug opened:
> https://issues.jboss.org/browse/ENTESB-3959
>
>
> However, I fear that this is a problem in the aries blueprint
> implementation as I'm not using KARAF nor FUSE, just a plain
> osgi container. Either that or I'm missing some blueprint
> configuration. I'm basically using blueprint:cm
>
>
> As a workaround I can make a config file per bundle that needs
> it....
>
> As follows the versions and bundles that I'm using related to
> the container (Running on top of Equinox 3.11):
>
> ID|State |Level|Name
> 5|Active | 2|Apache Aries Whiteboard support for
> JMX DynamicMBean services (1.1.5)|1.1.5
> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
> 13|Active | 3|Aries Remote Service Admin Topology
> Manager (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
> 25|Active | 3|Aries Remote Service Admin Discovery
> Gogo Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
> 29|Active | 2|Apache Aries JMX Blueprint Core
> (1.1.5)|1.1.5
> 37|Active | 2|Apache Aries JNDI URL Handler
> (1.1.0)|1.1.0
> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
> 47|Resolved | 4|Apache Aries Blueprint Core
> Compatiblity Fragment Bundle (1.0.0)|1.0.0
> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
> 56|Active | 2|Aries JPA Container Managed Contexts
> (1.0.4)|1.0.4
> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
> 67|Active | 3|Aries Remote Service Admin Service
> Provider Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 71|Active | 2|Apache Aries Transaction Blueprint
> (1.1.1)|1.1.1
> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
> 77|Active | 2|Apache Aries JNDI Support for Legacy
> Runtimes (1.0.0)|1.0.0
> 88|Active | 2|Apache Aries JMX Blueprint API
> (1.1.5)|1.1.5
> 89|Active | 2|Apache Aries Transaction Manager
> (1.3.0)|1.3.0
> 94|Active | 3|Aries Remote Service Admin Discovery
> Config (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 97|Active | 3|Aries Remote Service Admin provider
> TCP (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 110|Active | 2|Apache Aries Blueprint Annotation API
> (1.0.1)|1.0.1
> 120|Active | 2|Apache Aries Transaction Blueprint
> (2.1.0)|2.1.0
> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
> 130|Active | 2|Apache Aries Blueprint Annotation Impl
> (1.0.1)|1.0.1
> 132|Active | 3|Aries Remote Service Admin Discovery
> Zookeeper (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 134|Active | 3|Aries Remote Service Admin Discovery
> Local (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 138|Active | 3|Aries Remote Service Admin Core
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 139|Active | 2|Apache Aries JNDI RMI Handler
> (1.0.0)|1.0.0
> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving
> Bundle (1.0.8)|1.0.8
> 147|Active | 2|Aries JPA Container blueprint
> integration for Aries blueprint (1.0.4)|1.0.4
>
> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
> 104|Active | 4|Apache Felix Coordinator Service
> (1.0.2)|1.0.2
> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
> 114|Active | 4|Apache Felix Web Management Console
> (1.2.8)|1.2.8
> 148|Active | 4|Apache Felix Configuration Admin
> Service (1.8.8)|1.8.8
>
> 0|Active | 0|OSGi System Bundle
> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>
>
> --
> WARNING: Computer viruses can be transmitted via email. The
> recipient should check this email and any attachments for the
> presence of viruses. The company accepts no liability for any
> damage caused by any virus transmitted by this email. E-mail
> transmission cannot be guaranteed to be secure or error-free
> as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The
> sender therefore does not accept liability for any errors or
> omissions in the contents of this message, which arise as a
> result of e-mail transmission.
>
> Warning: Although the company has taken reasonable precautions
> to ensure no viruses are present in this email, the company
> cannot accept responsibility for any loss or damage arising
> from the use of this email or attachments.
>
>
>
>
>
> --
> *Raymond Aug�*
> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect *Liferay, Inc.*
> <http://www.liferay.com> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
Re: blueprint:cm multiple bundle but same config file
Posted by Raymond Auge <ra...@liferay.com>.
As long as configurations are not bound to a bundle they can be used by any
bundle.
The exception clearly shows that the configuration is bound to a bundle.
Creating an unbound configuration requires passing a "?" as the second
arguments to getConfiguration/createFactoryConfiguration methods of CM.
HTH,
- Ray
On Thu, Jul 7, 2016 at 10:24 AM, Brad Johnson <br...@mediadriver.com>
wrote:
> I don't think that's possible.
>
> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
> wrote:
>
>> Hello All,
>>
>> Is it possible to use same config file from multiple bundles
>> while using Config Admin with blueprint Blueprint? Because, I can't manage
>> to do that, I get the following error:
>>
>> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm.ManagedService,
>> id=214, bundle=86/initial@reference:file:../plugin-1/]: No visibility to
>> configuration bound to initial@reference:file:../plugin-2/
>>
>>
>> I saw in this jira a bug opened:
>> https://issues.jboss.org/browse/ENTESB-3959
>>
>>
>> However, I fear that this is a problem in the aries blueprint
>> implementation as I'm not using KARAF nor FUSE, just a plain osgi
>> container. Either that or I'm missing some blueprint configuration. I'm
>> basically using blueprint:cm
>>
>>
>> As a workaround I can make a config file per bundle that needs it....
>>
>> As follows the versions and bundles that I'm using related to the
>> container (Running on top of Equinox 3.11):
>>
>> ID|State |Level|Name
>> 5|Active | 2|Apache Aries Whiteboard support for JMX
>> DynamicMBean services (1.1.5)|1.1.5
>> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
>> 13|Active | 3|Aries Remote Service Admin Topology Manager
>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
>> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
>> 25|Active | 3|Aries Remote Service Admin Discovery Gogo
>> Commands (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
>> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
>> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
>> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
>> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
>> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment
>> Bundle (1.0.0)|1.0.0
>> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
>> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
>> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
>> 67|Active | 3|Aries Remote Service Admin Service Provider
>> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
>> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
>> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes
>> (1.0.0)|1.0.0
>> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
>> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
>> 94|Active | 3|Aries Remote Service Admin Discovery Config
>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 97|Active | 3|Aries Remote Service Admin provider TCP
>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 110|Active | 2|Apache Aries Blueprint Annotation API
>> (1.0.1)|1.0.1
>> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
>> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
>> 130|Active | 2|Apache Aries Blueprint Annotation Impl
>> (1.0.1)|1.0.1
>> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper
>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 134|Active | 3|Aries Remote Service Admin Discovery Local
>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 138|Active | 3|Aries Remote Service Admin Core
>> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
>> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
>> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
>> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
>> (1.0.8)|1.0.8
>> 147|Active | 2|Aries JPA Container blueprint integration for
>> Aries blueprint (1.0.4)|1.0.4
>>
>> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
>> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
>> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
>> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
>> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
>> 148|Active | 4|Apache Felix Configuration Admin Service
>> (1.8.8)|1.8.8
>>
>> 0|Active | 0|OSGi System Bundle
>> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>>
>>
>> --
>> WARNING: Computer viruses can be transmitted via email. The recipient
>> should check this email and any attachments for the presence of viruses.
>> The company accepts no liability for any damage caused by any virus
>> transmitted by this email. E-mail transmission cannot be guaranteed to be
>> secure or error-free as information could be intercepted, corrupted, lost,
>> destroyed, arrive late or incomplete, or contain viruses. The sender
>> therefore does not accept liability for any errors or omissions in the
>> contents of this message, which arise as a result of e-mail transmission.
>>
>> Warning: Although the company has taken reasonable precautions to ensure
>> no viruses are present in this email, the company cannot accept
>> responsibility for any loss or damage arising from the use of this email or
>> attachments.
>>
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: blueprint:cm multiple bundle but same config file
Posted by Brad Johnson <br...@mediadriver.com>.
I don't think that's possible.
On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <pa...@faw.jku.at>
wrote:
> Hello All,
>
> Is it possible to use same config file from multiple bundles
> while using Config Admin with blueprint Blueprint? Because, I can't manage
> to do that, I get the following error:
>
> MESSAGE Cannot use configuration test.mybundle for [org.osgi.service.cm.ManagedService,
> id=214, bundle=86/initial@reference:file:../plugin-1/]: No visibility to
> configuration bound to initial@reference:file:../plugin-2/
>
>
> I saw in this jira a bug opened:
> https://issues.jboss.org/browse/ENTESB-3959
>
>
> However, I fear that this is a problem in the aries blueprint
> implementation as I'm not using KARAF nor FUSE, just a plain osgi
> container. Either that or I'm missing some blueprint configuration. I'm
> basically using blueprint:cm
>
>
> As a workaround I can make a config file per bundle that needs it....
>
> As follows the versions and bundles that I'm using related to the
> container (Running on top of Equinox 3.11):
>
> ID|State |Level|Name
> 5|Active | 2|Apache Aries Whiteboard support for JMX
> DynamicMBean services (1.1.5)|1.1.5
> 6|Active | 2|Apache Aries JNDI Core (1.0.2)|1.0.2
> 13|Active | 3|Aries Remote Service Admin Topology Manager
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 15|Active | 2|Aries JPA Container (1.0.2)|1.0.2
> 21|Active | 2|Apache Aries JNDI API (1.1.0)|1.1.0
> 25|Active | 3|Aries Remote Service Admin Discovery Gogo Commands
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 27|Active | 2|Apache Aries Blueprint CM (1.0.7)|1.0.7
> 29|Active | 2|Apache Aries JMX Blueprint Core (1.1.5)|1.1.5
> 37|Active | 2|Apache Aries JNDI URL Handler (1.1.0)|1.1.0
> 42|Active | 2|Apache Aries JMX Core (1.1.5)|1.1.5
> 46|Active | 2|Apache Aries Blueprint Core (1.5.0)|1.5.0
> 47|Resolved | 4|Apache Aries Blueprint Core Compatiblity Fragment
> Bundle (1.0.0)|1.0.0
> 55|Active | 2|Apache Aries Util (1.1.1)|1.1.1
> 56|Active | 2|Aries JPA Container Managed Contexts (1.0.4)|1.0.4
> 59|Active | 2|Apache Aries Proxy API (1.0.1)|1.0.1
> 67|Active | 3|Aries Remote Service Admin Service Provider
> Interface (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 71|Active | 2|Apache Aries Transaction Blueprint (1.1.1)|1.1.1
> 73|Active | 2|Aries JPA Container API (1.0.2)|1.0.2
> 77|Active | 2|Apache Aries JNDI Support for Legacy Runtimes
> (1.0.0)|1.0.0
> 88|Active | 2|Apache Aries JMX Blueprint API (1.1.5)|1.1.5
> 89|Active | 2|Apache Aries Transaction Manager (1.3.0)|1.3.0
> 94|Active | 3|Aries Remote Service Admin Discovery Config
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 97|Active | 3|Aries Remote Service Admin provider TCP
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 110|Active | 2|Apache Aries Blueprint Annotation API (1.0.1)|1.0.1
> 120|Active | 2|Apache Aries Transaction Blueprint (2.1.0)|2.1.0
> 123|Active | 2|Apache Aries JMX API (1.1.5)|1.1.5
> 130|Active | 2|Apache Aries Blueprint Annotation Impl
> (1.0.1)|1.0.1
> 132|Active | 3|Aries Remote Service Admin Discovery Zookeeper
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 134|Active | 3|Aries Remote Service Admin Discovery Local
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 138|Active | 3|Aries Remote Service Admin Core
> (1.9.0.SNAPSHOT)|1.9.0.SNAPSHOT
> 139|Active | 2|Apache Aries JNDI RMI Handler (1.0.0)|1.0.0
> 143|Active | 2|Apache Aries Proxy Service (1.0.4)|1.0.4
> 146|Active | 2|Apache Aries SPI Fly Dynamic Weaving Bundle
> (1.0.8)|1.0.8
> 147|Active | 2|Aries JPA Container blueprint integration for
> Aries blueprint (1.0.4)|1.0.4
>
> 11|Active | 4|Apache Felix File Install (3.5.4)|3.5.4
> 19|Active | 4|Apache Felix Gogo Shell (0.12.0)|0.12.0
> 57|Active | 4|Apache Felix Gogo Command (0.16.0)|0.16.0
> 104|Active | 4|Apache Felix Coordinator Service (1.0.2)|1.0.2
> 109|Active | 4|Apache Felix Gogo Runtime (0.16.2)|0.16.2
> 114|Active | 4|Apache Felix Web Management Console (1.2.8)|1.2.8
> 148|Active | 4|Apache Felix Configuration Admin Service
> (1.8.8)|1.8.8
>
> 0|Active | 0|OSGi System Bundle
> (3.11.0.v20160603-1336)|3.11.0.v20160603-1336
>
>
> --
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email. E-mail transmission cannot be guaranteed to be
> secure or error-free as information could be intercepted, corrupted, lost,
> destroyed, arrive late or incomplete, or contain viruses. The sender
> therefore does not accept liability for any errors or omissions in the
> contents of this message, which arise as a result of e-mail transmission.
>
> Warning: Although the company has taken reasonable precautions to ensure
> no viruses are present in this email, the company cannot accept
> responsibility for any loss or damage arising from the use of this email or
> attachments.
>