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]>
