Guillaume,
I'm still using Blueprint and have found Camel/SCR to be a pain to work
with. It provides no tangible benefit if one is using Blueprint for routes
and dependency injection anyway as it simply introduces one more way of
configuring things. It was interesting to read the other day that Christian
seems to have the same impression of the complexity of SCR. I remember
when I first tried I thought it looked pretty cool but started running into
problems. That DS is in its second generation and only now getting around
to transactions is telling. Either it has reached its natural boundaries
and is now over-reaching or wasn't full thought out. To me it's a
component and service bootstrapping mechanism which represents a small
portion of the world I work in - transforms, routing, EIPs, etc. I've no
reason to embrace it or deny it unless it either makes my job much easier
or I can't live without it. So far adding Camel SCR and DS into the
middleware just results in one more thing I have to deal with.
I think Blueprint works well these days and has come a long way in the past
3 years. The Aries team is to be commended for some great work. I've been
surprised by the near religious zeal of some of the DS advocates. I'll be
interested in seeing the DS semantics and proxies for CDI. Heh. Proxies are
another technology that I don't care about one way or the other as long as
things work well and don't require a lot of configuration. So it's great
if we can get rid of proxies but not so great if I now have to trade that
off for configuration of start up order on services to make sure everything
is running before Camel routes come up.
On Tue, Jul 12, 2016 at 10:57 AM, Guillaume Nodet <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/
>
>
