The CamelContext disambiguation obviously is a next step...
On Mon, Aug 1, 2016 at 8:01 PM, Brad Johnson <brad.john...@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 <boa...@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.john...@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 <timothyjw...@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.john...@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
>>>> timothyjw...@apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <gno...@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.john...@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.john...@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.go...@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.john...@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 <boa...@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.john...@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_jen...@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 <seij...@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.john...@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_jen...@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.john...@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.john...@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.a...@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_jen...@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.a...@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_jen...@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.go...@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.john...@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.go...@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 <boa...@gmail.com>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Red Hat, Open Source Integration
>>>>>
>>>>> Email: gno...@redhat.com
>>>>> Web: http://fusesource.com
>>>>> Blog: http://gnodet.blogspot.com/
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Matt Sicker <boa...@gmail.com>
>>
>
>
