In my experience it would first help to look at the library. In my experience
most libraries provide a simple registration process in addition to the
automatic discovery. A trivial component using a BundleTracker can then handle
this specific case.
I’ve seen so many cases where people spend a lot of effort to get a generic
solution while a few lines of specific code would be fine.
Obviously in this case I’ve not looked.
Kind regards,
Peter Kriens
> On 8 Dec 2016, at 22:20, Daghan ACAY <daghana...@hotmail.com> wrote:
>
> I do not wish an alternative solution but application note here might give a
> fresh perspective http://enroute.osgi.org/appnotes/interceptors.html as an
> alternative to weaving.
>
> Cheers
> Daghan
>
> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails
> as clean, short chats.
>
>
>
> -------- Original Message --------
> From: Christian Schneider <ch...@die-schneider.net>
> Sent: Thursday, December 8, 2016 09:20 PM
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Subject: Re: [osgi-dev] Strange issue with enRoute and Aries SPI Fly.
>
> I think the really problematic thing in Aries-spi is the client side.
> On the server side I think it makes sense to look into the bundles and
> provide the ServiceLoader services as OSGi services.
>
> On the client side it only works if Aries-spi does the weaving early enough.
> So I wonder if in many cases we could just change the client side and still
> profit from the Aries-spi services.
> Not sure if this can work for the sound support though.
>
> Christian
>
> On 08.12.2016 09:35, Peter Kriens wrote:
>> Runtime weaving is always one of the worst programming hacks in existence, I
>> would avoid it like the plague at all costs. It looks so attractive but it
>> causes so much unexpected pain.
>>
>> However, you probably can’t. So I guess the like problem is that your UI
>> code gets loaded before the weaver is installed. If you weaver uses the OSGi
>> API to weave then it registers a Weaving Hook service. What you should do is
>> make your GUI code depend on that service, you should make the hook also
>> immediate. This will prohibit your code from loading before the weaving
>> hooks is established. If you have a domain service that is registered by the
>> weaver as it seems depend on that one.
>>
>> However, absolute best advice is to dump the dynamic weaving solution and
>> find a way to register the plugin directly with the SPI.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>> On 7 Dec 2016, at 18:38, Elliot Huntington <elliot.hunting...@gmail.com
>>> <mailto:elliot.hunting...@gmail.com>> wrote:
>>>
>>> Hi Peter,
>>>
>>> Yes, I also assume I am running the application without security. I have
>>> tested this two ways, one by running the enRoute application directly
>>> within Eclipse just as explained in the enRoute tutorials, and also by
>>> exporting the enRoute application as a stand alone executable jar file. In
>>> both cases the behavior is the same. I agree with your suggestion to
>>> eliminate as much as possible to identify what the problem is. Actually,
>>> that was my motivation for creating this github project. I wanted to create
>>> a SSCCE <http://sscce.org/> to share with others in order to get the help I
>>> need to figure this out.
>>>
>>> In order to make this problem more clear I updated the example
>>> (https://github.com/axiopisty/com.github.axiopisty.plarpebu
>>> <https://github.com/axiopisty/com.github.axiopisty.plarpebu>) to isolate
>>> the code that integrates the SPI Fly dynamic weaving. The latest commit on
>>> this project allows the dynamic weaving feature to be configured on or off
>>> with a checkbox in the GUI. I tested this quite thoroughly. With dynamic
>>> weaving disabled, the MediaPlayer load method works the exact same from
>>> either the command line or the GUI. But with dynamic weaving enabled it
>>> only works as expected from the command line using the Gogo Shell.
>>>
>>> The problem is beyond my scope of knowledge or expertise in either OSGi or
>>> Apache Aries SPI Fly. This is why I'm reaching out to you experts in the
>>> OSGi and Aries communities.
>>>
>>> Sincerely,
>>> Elliot
>>>
>>> On Tue, Dec 6, 2016 at 2:20 AM, Peter Kriens <
>>> <mailto:peter.kri...@aqute.biz>peter.kri...@aqute.biz
>>> <mailto:peter.kri...@aqute.biz>> wrote:
>>> Since the system is all started up when you press play or use the gogo
>>> command this does not look like a start ordering problem. Nor is it a R/C
>>> problem because all is satisfied.
>>>
>>> The path from Gogo must therefore follow a different trajectory. The best
>>> way to find these things out is to single step both paths and try to find a
>>> difference. It might also help to remove as much functionality as possible
>>> to focus on the different paths. I.e. try to remove the weaving to
>>> include/exclude that as cause.
>>>
>>> I assume you run without security?
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>>> On 5 Dec 2016, at 21:48, Elliot Huntington <
>>>> <mailto:elliot.hunting...@gmail.com>elliot.hunting...@gmail.com
>>>> <mailto:elliot.hunting...@gmail.com>> wrote:
>>>>
>>>> @BJ Hargrave,
>>>>
>>>> Yes, I just tested rearranging the items listed in -runbundles to make
>>>> sure the ones that should be loaded first are. The problem remains.
>>>>
>>>> @Raymond Auge,
>>>>
>>>> I'm having a hard time understanding your response. I think I generally
>>>> understand what you're saying, but I don't know what to look for as far as
>>>> what should specifically be in the set of requirements/capabilities for
>>>> this use case. But I think the essence of your response is that if the
>>>> requirements and capabilities are not properly configured in the bundles
>>>> then the bundles wont even resolve properly much less activate properly?
>>>>
>>>> I'm quite certain that I have properly configured the
>>>> requirements/capabilities in the media player bundle which depends on the
>>>> dynamic weaving bundle, otherwise I don't think loading the MP3 file would
>>>> work properly from the gogo shell, which it does. I just don't understand
>>>> why it works from the shell but not from the GUI.
>>>>
>>>>
>>>> In case it helps, here is the output of listing the installed bundles in
>>>> the framework. I'm assuming that since the ASM, Util, and Dynamic Weaving
>>>> bundles are loaded first that the start level configuration is not
>>>> required (as indicated in BJ's response).
>>>>
>>>> G! lb
>>>> lb
>>>> START LEVEL 1
>>>> ID|State |Level|Name
>>>> 0|Active | 0|OSGi System Bundle
>>>> (3.10.100.v20150529-1857)|3.10.100.v20150529-1857
>>>> 1|Active | 1|ASM all classes with debug info (5.1.0)|5.1.0
>>>> 2|Active | 1|Apache Aries Util (1.1.3)|1.1.3
>>>> 3|Active | 1|Apache Aries SPI Fly Dynamic Weaving Bundle
>>>> (1.0.8)|1.0.8
>>>> 4|Active | 1|tritonus-share (0.3.7.4)|0.3.7.4
>>>> 5|Active | 1|JLayer (1.0.1.4)|1.0.1.4
>>>> 6|Active | 1|MP3SPI (1.9.5.4)|1.9.5.4
>>>> 7|Active | 1|Apache Felix Configuration Admin Service
>>>> (1.8.8)|1.8.8
>>>> 8|Active | 1|Apache Felix Log Service (1.0.1)|1.0.1
>>>> 9|Active | 1|Apache Felix Declarative Services (2.0.2)|2.0.2
>>>> 10|Active | 1|Meta Type
>>>> (1.4.100.v20150408-1437)|1.4.100.v20150408-1437
>>>> 11|Active | 1|org.osgi:org.osgi.service.metatype
>>>> (1.3.0.201505202024)|1.3.0.201505202024
>>>> 12|Active | 1|Apache Felix Gogo Command (0.16.0)|0.16.0
>>>> 13|Active | 1|Apache Felix Gogo Runtime (0.16.2)|0.16.2
>>>> 14|Active | 1|OSGi enRoute Gogo Shell
>>>> (2.0.0.201610141744)|2.0.0.201610141744
>>>> 15|Active | 1|com.github.axiopisty.plarpebu.mediaplayer.provider
>>>> (1.0.0.201612052005)|1.0.0.201612052005
>>>> 16|Active |
>>>> 1|com.github.axiopisty.plarpebu.javafx.launcher.provider
>>>> (1.0.0.201611291642)|1.0.0.201611291642
>>>> 17|Active | 1|com.github.axiopisty.plarpebu.application
>>>> (1.0.0.201612052007)|1.0.0.201612052007
>>>>
>>>>
>>>> The headers for the media player provider bundle are:
>>>>
>>>> G! headers 15
>>>> headers 15
>>>>
>>>> com.github.axiopisty.plarpebu.mediaplayer.provider (15)
>>>> -------------------------------------------------------
>>>> Manifest-Version = 1.0
>>>> Bnd-LastModified = 1480968335538
>>>> Bundle-Description = MP3 MediaPlayer
>>>> Bundle-ManifestVersion = 2
>>>> Bundle-Name = com.github.axiopisty.plarpebu.mediaplayer.provider
>>>> Bundle-SymbolicName = com.github.axiopisty.plarpebu.mediaplayer.provider
>>>> Bundle-Version = 1.0.0.201612052005
>>>> Created-By = 1.8.0_60 (Oracle Corporation)
>>>> Export-Package =
>>>> com.github.axiopisty.plarpebu.mediaplayer.api;version="1.0.0"
>>>> Import-Package =
>>>> com.github.axiopisty.plarpebu.mediaplayer.api;version="[1.0,1.1)",javax.sound.sampled
>>>> Private-Package =
>>>> com.github.axiopisty.plarpebu.mediaplayer.mp3.provider,com.github.axiopisty.plarpebu.mediaplayer.mp3.provider.internal
>>>> Provide-Capability =
>>>> osgi.service;objectClass:List<String>="com.github.axiopisty.plarpebu.mediaplayer.api.MediaPlayer"
>>>> Require-Capability = osgi.ee <http://osgi.ee/>;filter:="(&(osgi.ee
>>>> <http://osgi.ee/>=JavaSE)(version=1.8))"
>>>> Service-Component =
>>>> OSGI-INF/com.github.axiopisty.plarpebu.mediaplayer.mp3.xml
>>>> SPI-Consumer = javax.sound.sampled.AudioSystem#getAudioInputStream
>>>> Tool = Bnd-3.3.0.201609221906
>>>>
>>>>
>>>> With the application running, the GUI loads properly. But if you click on
>>>> the Load button and then select an MP3 file the application reports the
>>>> following:
>>>>
>>>> load: AG1001-01 - Cat Stevens - Wild World.mp3
>>>> java.lang.IllegalArgumentException: No line matching interface
>>>> SourceDataLine supporting format PCM_SIGNED 44100.0 Hz, 16 bit, stereo, 4
>>>> bytes/frame, little-endian is supported.
>>>> at javax.sound.sampled.AudioSystem.getLine(AudioSystem.java:479)
>>>> at
>>>> com.github.axiopisty.plarpebu.mediaplayer.mp3.provider.internal.MP3Player.<init>(MP3Player.java:45)
>>>> at
>>>> com.github.axiopisty.plarpebu.mediaplayer.mp3.provider.KaraokePlayer.initialize(KaraokePlayer.java:52)
>>>> at
>>>> com.github.axiopisty.plarpebu.mediaplayer.mp3.provider.KaraokePlayer.load(KaraokePlayer.java:42)
>>>> at
>>>> com.github.axiopisty.plarpebu.application.Plarpebu.lambda$3(Plarpebu.java:77)
>>>> at
>>>> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
>>>> at
>>>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238)
>>>> at
>>>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
>>>> at
>>>> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
>>>> at
>>>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
>>>> at
>>>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>>>> at
>>>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>>>> at
>>>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>>>> at
>>>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>>>> at
>>>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>>>> at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
>>>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
>>>> at javafx.event.Event.fireEvent(Event.java:198)
>>>> at javafx.scene.Node.fireEvent(Node.java:8411)
>>>> at javafx.scene.control.Button.fire(Button.java:185)
>>>> at
>>>> com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:182)
>>>> at
>>>> com.sun.javafx.scene.control.skin.BehaviorSkinBase$1.handle(BehaviorSkinBase.java:96)
>>>> at
>>>> com.sun.javafx.scene.control.skin.BehaviorSkinBase$1.handle(BehaviorSkinBase.java:89)
>>>> at
>>>> com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218)
>>>> at
>>>> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
>>>> at
>>>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238)
>>>> at
>>>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
>>>> at
>>>> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
>>>> at
>>>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
>>>> at
>>>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>>>> at
>>>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>>>> at
>>>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>>>> at
>>>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>>>> at
>>>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>>>> at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
>>>> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
>>>> at javafx.event.Event.fireEvent(Event.java:198)
>>>> at javafx.scene.Scene$MouseHandler.process(Scene.java:3757)
>>>> at javafx.scene.Scene$MouseHandler.access$1500(Scene.java:3485)
>>>> at javafx.scene.Scene.impl_processMouseEvent(Scene.java:1762)
>>>> at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2494)
>>>> at
>>>> com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:352)
>>>> at
>>>> com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:275)
>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>> at
>>>> com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$355(GlassViewEventHandler.java:388)
>>>> at
>>>> com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:389)
>>>> at
>>>> com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:387)
>>>> at com.sun.glass.ui.View.handleMouseEvent(View.java:555)
>>>> at com.sun.glass.ui.View.notifyMouse(View.java:937)
>>>> at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
>>>> at
>>>> com.sun.glass.ui.gtk.GtkApplication.lambda$null$50(GtkApplication.java:139)
>>>> at java.lang.Thread.run(Thread.java:745)
>>>>
>>>>
>>>> However, if you issue the following command at the gogo shell you get:
>>>>
>>>> G! mp3:load "/home/ehuntington/projects/research/Tracks/AG1001/AG1001-01 -
>>>> Cat Stevens - Wild World.mp3"
>>>> mp3:load "/home/ehuntington/projects/research/Tracks/AG1001/AG1001-01 -
>>>> Cat Stevens - Wild World.mp3"
>>>> MP3Player run entered.
>>>> load: AG1001-01 - Cat Stevens - Wild World.mp3
>>>> state = PlayerState.INITIALIZED
>>>>
>>>> After doing this you can then either click the play button in the GUI or
>>>> use the gogo command "mp3:play" and the song plays as expected.
>>>>
>>>> What am I missing? I just don't understand why loading the mp3 file works
>>>> as expected when using the gogo commands but not from within the gui.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Dec 5, 2016 at 12:19 PM, Raymond Auge <
>>>> <mailto:raymond.a...@liferay.com>raymond.a...@liferay.com
>>>> <mailto:raymond.a...@liferay.com>> wrote:
>>>> Properly configuring the SPI-Fly integration should result in a set of
>>>> requirement and capabilities on the target bundles causing them to have a
>>>> resolution time requirement which should force the weaving to affect them
>>>> in the correct order.
>>>>
>>>> For instance, if you have API bundle X that requires bundle Z providing an
>>>> impl via service loader:
>>>>
>>>> - Bundle Z(provider) should have
>>>> a) a requirement on a service mediator registrar
>>>> b) a capability for the service mediator provider for the API in
>>>> question
>>>> c) after weaving (which must occur due to a), have published Z's impl
>>>> into the service registry
>>>>
>>>> - Bundle X(api) should have
>>>> a) a requirement for the service mediator processor
>>>> b) a requirement on service mediator provider for the API in question
>>>> c) after weaving (which must occur due to a), have OSGi service
>>>> registry code for obtaining the impl
>>>>
>>>> when properly done neither of X or Y could reach "ACTIVE" or even
>>>> "RESOLVE" state unless the service mediator (Spi-Fly) has done it's job of
>>>> weaving.
>>>>
>>>> See the notes at
>>>> <http://aries.apache.org/modules/spi-fly.html>http://aries.apache.org/module
>>>> <http://aries.apache.org/module>s/spi-fly.html
>>>>
>>>> Sincerely,
>>>> - Ray
>>>>
>>>>
>>>> On Mon, Dec 5, 2016 at 1:56 PM, BJ Hargrave <
>>>> <mailto:hargr...@us.ibm.com>hargr...@us.ibm.com
>>>> <mailto:hargr...@us.ibm.com>> wrote:
>>>> I am not aware of any support in -runbundles to set start levels for
>>>> bundle. But the bnd launcher should start the bundle in the order they are
>>>> specified on the -runbundles instruction. Did you try putting those
>>>> bundles first that need to be started first?
>>>>
>>>> --
>>>>
>>>> BJ Hargrave
>>>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>>>> <tel:%28386%29%20848-1781>
>>>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>>>> <tel:%28386%29%20848-3788>
>>>> <mailto:hargr...@us.ibm.com>hargr...@us.ibm.com
>>>> <mailto:hargr...@us.ibm.com>
>>>>
>>>>
>>>> ----- Original message -----
>>>> From: Elliot Huntington <
>>>> <mailto:elliot.hunting...@gmail.com>elliot.hunting...@gmail.com
>>>> <mailto:elliot.hunting...@gmail.com>>
>>>> Sent by:
>>>> <mailto:osgi-dev-boun...@mail.osgi.org>osgi-dev-boun...@mail.osgi.org
>>>> <mailto:osgi-dev-boun...@mail.osgi.org>
>>>> To: OSGi Developer Mail List <
>>>> <mailto:osgi-dev@mail.osgi.org>osgi-dev@mail.osgi.org
>>>> <mailto:osgi-dev@mail.osgi.org>>
>>>> Cc:
>>>> Subject: [osgi-dev] Strange issue with enRoute and Aries SPI Fly.
>>>> Date: Mon, Dec 5, 2016 1:35 PM
>>>>
>>>> The motivation for this thread is that I am experimenting with an OSGi
>>>> enRoute project that uses the Apache Aries SPI-Fly dynamic weaving
>>>> libraries to play an MP3 file. The example project is on github at:
>>>> <https://github.com/axiopisty/com.github.axiopisty.plarpebu>https://github.com/axiopisty/c
>>>> <https://github.com/axiopisty/c>om.github.axiopisty.plarpebu. This
>>>> project has 5 enRoute modules:
>>>> JavaFX API
>>>> JavaFX API Provider
>>>> Media Player API
>>>> Media Player API Provider
>>>> Application
>>>> What I have noticed is that when I use 'osgi.enroute.debug.api' I can use
>>>> the debug commands in the gogo shell to successfully load, play, pause,
>>>> and stop the media player. The application will successfully play an MP3
>>>> file. However, when using the GUI to 'load' the MP3 file an exception
>>>> occurs that indicates something is not working right with the SPI Fly
>>>> dynamic weaving integration. I have not been able to figure out why the
>>>> 'load' operation works successfully when using the gogo shell, but does
>>>> not work when called from the GUI. I'm wondering if it might have
>>>> something to do with the bundle start levels because according to the SPI
>>>> Fly documentation, "any OSGi Bundle that uses the OSGi 4.3 WeavingHooks,
>>>> the weaver bundle (org.apache.aries.spifly.dynamic.bundle) needs to be
>>>> active before any bundles that need to be dynamically woven. OSGi start
>>>> levels can provide a mechanism to control this."
>>>>
>>>> My suspicion is that because the JavaFX provider is a DS component with
>>>> scope SINGLETON and immediate = true, that this bundle is activated before
>>>> the dynamic weaving bundle in the runtime, which is probably causing the
>>>> problem described.
>>>>
>>>> So my question is, when using bnd, is there some directive or syntax that
>>>> can be used with the -runbundles directive that indicates the bundle start
>>>> level?
>>>>
>>>> I would greatly appreciate your help figuring out why the media player
>>>> service I created in this example works successfully from the gogo shell,
>>>> but not from the gui, all within the same runtime application.
>>>>
>>>> Sincerely,
>>>> Elliot
>>>>
>>>>
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> <mailto:osgi-dev@mail.osgi.org>osgi-dev@mail.osgi.org
>>>> <mailto:osgi-dev@mail.osgi.org>
>>>>
>>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>https://mail.osgi.org/mailman/
>>>> <https://mail.osgi.org/mailman/>listinfo/osgi-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> <mailto:osgi-dev@mail.osgi.org>osgi-dev@mail.osgi.org
>>>> <mailto:osgi-dev@mail.osgi.org>
>>>>
>>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>https://mail.osgi.org/mailman/
>>>> <https://mail.osgi.org/mailman/>listinfo/osgi-dev
>>>>
>>>>
>>>>
>>>> --
>>>> 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)
>>>>
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>>>
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
> --
> Christian Schneider
> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>
> Open Source Architect
> http://www.talend.com <http://www.talend.com/>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
