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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
>> 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 <[email protected]>
>>> 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
>>> [email protected]
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <[email protected]>
>>> 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 <[email protected]>:
>>>>
>>>>> 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 <
>>>>> [email protected]> 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 <
>>>>>> [email protected]> 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 <
>>>>>>> [email protected]> 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 <[email protected]>
>>>>>>> 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 <[email protected]
>>>>>>>> > 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 <
>>>>>>>>> [email protected]> 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 <[email protected]>
>>>>>>>>>> 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 <
>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't think that's possible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Jul 7, 2016 at 8:51 AM, Pablo Gómez Pérez <
>>>>>>>>>>>>>>>> [email protected]> 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 <[email protected]>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Red Hat, Open Source Integration
>>>>
>>>> Email: [email protected]
>>>> Web: http://fusesource.com
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>>>
>>>
>>>
>>
>
>
> --
> Matt Sicker <[email protected]>
>
