You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Brad Johnson <br...@mediadriver.com> on 2016/07/13 21:40:47 UTC
Re: blueprint:cm multiple bundle but me config file
multilocation sounds fantastic. Can't wait for the day. I'm curious, do
you think we don't quite understand the concept? It really isn't that
difficult. How does that work in R4 David? Blueprint isn't getting updated
anymore so I can't imagine it going in anytime soon. Besides from what I
can see OSGI group seems to be inhabited by anti-blueprint, DS zealots.
That isn't how this works worth the Maven mojos. Generate everything,
install via features and later if you want to install a crosscut ting
change you modify that shared property and the filtered resources put them
in the appropriate cfg file and build that into the bundle. Rerun the
features install and overwrite the cfg. If you reuse a port in five cfg
files, then you change that in a shared properties file which is loaded.
When the filtered cfg files are written out, the port gets filled in. Want
to change the port? Simply modify the propetry, rerun the build and simply
reinstall the features.
Most of that would be pretty automatic. Check in your properties to source
control, build kicks off in Jenkins, bundle of cfg files is created and
installed in Nexus. Rerun your features install and pick up all the
changed cfg's.
That takes one configuration bundle. One properties and resources plug-in
configuration and you are done.
Or you can get involved in trying to get some interest in adding something
to blueprint from the OSGI group who are actively hostile to blueprint. We
can wish that maybe the large chunk of us who live with karaf 2.x and R4
might somehow get the crumb of features handed down.
My concern is the near monomania for DS in the OSGI group as if solving
that one very hairy problem is going to yield an abundance.
From my perspective we've lost almost 4 years to DS pipe dreams and
something as basic as Camel SCR is a mess and doesn't seem much used much
less loved by anyone.
Four years ago I thought OSGI was on the cusp of a breakout. I'm pretty
sure that isn't the case anymore. Was DS navel gazing responsible? It
contributed. Especially all the shouting down of technologyes that don't
contribute toward the DS dream .
Interestingly there are so many of us involved in OSGI and Camel and
blueprint who are now looking for our next home. Where will I be doing
Middleware development in 5 years? Probably still use Camel and Maven.
OSGI? Perhaps not.
On Jul 11, 2016 5:31 PM, "David Jencks" <da...@yahoo.com> 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 <
>>>>> 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é* (@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>
>
Re: blueprint:cm multiple bundle but me config file
Posted by David Jencks <da...@yahoo.com>.
I started out in OSGI as a blueprint zealot (I wrote xbean-blueprint, for instance, partly to help integrate activemq into geronimo 3). After being forced nearly against my will to do some DS work, I came to see it’s advantages for the kinds of problems I work on, and at the moment can’t imagine problems that would long-term be better solved with blueprint. That doesn’t mean they don’t exist, and certainly doesn’t mean that for instance blueprint isn’t the best solution for running a project on both non-osgi spring and osgi. At the moment I’m in the fortunate position of not having to do that.
I’m quite sure that if anyone showed up and started working on an osgi blueprint spec update they would be welcomed. AFAIK no one has since IBM pushed the original spec through and more or less financed the development of the aries implementation. However, any spec update would be part of R7, not R4, so if you are constrained to an R4 environment a spec update wouldn’t do you any good.
I’m pretty sure that blueprint as it exists now would work fine with multi locations on something that has an R5+ config admin and a way to actually set the multilocation. I expect that if it doesn’t already support setting multiloication it would be nearly trivial to enhance karaf to do it. It would be nice to find out what happens.
If a vendor is leaving an osgi based product at R4 I would question their commitment to OSGI support. That’s not something the Apache Aries community can help much with AFAIK.
I”ve never actually used camel, but due to this discussion I just started looking at camel’s osgi usage and camel-scr. So far I’m somewhat surprised it works at all. It’s not always a good idea to try to wrap something designed to work in a javaee environment, full of ee-isms, into osgi as there are generally much simpler and more direct ways of solving problems than the ee-isms allow for. Possibly I may have some suggestions after I understand the code better. For instance, IIUC Christian mentioned that there are problems with optional dependencies not getting resolved at an appropriate time. This can often be solved using configuration, using a <target-name>.cardinaitly.minimum property to make the reference not optional.
With the small amount of camel knowledge I have so far, I’d think that the java DSL would generally be the easiest configuration route. Could you supply an example where you think xml is more convenient?
thanks
david jencks
> On Jul 13, 2016, at 2:40 PM, Brad Johnson <br...@mediadriver.com> wrote:
>
> multilocation sounds fantastic. Can't wait for the day. I'm curious, do you think we don't quite understand the concept? It really isn't that difficult. How does that work in R4 David? Blueprint isn't getting updated anymore so I can't imagine it going in anytime soon. Besides from what I can see OSGI group seems to be inhabited by anti-blueprint, DS zealots.
>
> That isn't how this works worth the Maven mojos. Generate everything, install via features and later if you want to install a crosscut ting change you modify that shared property and the filtered resources put them in the appropriate cfg file and build that into the bundle. Rerun the features install and overwrite the cfg. If you reuse a port in five cfg files, then you change that in a shared properties file which is loaded. When the filtered cfg files are written out, the port gets filled in. Want to change the port? Simply modify the propetry, rerun the build and simply reinstall the features.
>
> Most of that would be pretty automatic. Check in your properties to source control, build kicks off in Jenkins, bundle of cfg files is created and installed in Nexus. Rerun your features install and pick up all the changed cfg's.
>
> That takes one configuration bundle. One properties and resources plug-in configuration and you are done.
>
> Or you can get involved in trying to get some interest in adding something to blueprint from the OSGI group who are actively hostile to blueprint. We can wish that maybe the large chunk of us who live with karaf 2.x and R4 might somehow get the crumb of features handed down.
>
> My concern is the near monomania for DS in the OSGI group as if solving that one very hairy problem is going to yield an abundance.
>
> From my perspective we've lost almost 4 years to DS pipe dreams and something as basic as Camel SCR is a mess and doesn't seem much used much less loved by anyone.
>
> Four years ago I thought OSGI was on the cusp of a breakout. I'm pretty sure that isn't the case anymore. Was DS navel gazing responsible? It contributed. Especially all the shouting down of technologyes that don't contribute toward the DS dream .
>
> Interestingly there are so many of us involved in OSGI and Camel and blueprint who are now looking for our next home. Where will I be doing Middleware development in 5 years? Probably still use Camel and Maven. OSGI? Perhaps not.
>
> On Jul 11, 2016 5:31 PM, "David Jencks" <david_jencks@yahoo.com <ma...@yahoo.com>> 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 <boards@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 <seijoed@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é <> (@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 <boards@gmail.com <>>
>>
>