Re: [osgi-dev] Strange issue with enRoute and Aries SPI Fly.

2016-12-10 Thread Elliot Huntington
Peter,

Thank you for your suggestions. I modified the media player provider bundle
to also be scoped static and immediate, and included it as a runtime
dependency to the UI provider bundle. The problem still exists.

u...@aries.apache.org,

I'm including u...@aries.apache.org now to see if anyone from that list can
help me understand how SPI Fly works. I read the documentation on the
website which does mention that If you have an OSGi 4.3 (or higher)
compliant framework that supports WeavingHooks you can use the dynamic
weaving approach. Note that, as with any OSGi Bundle that uses the OSGi 4.3
WeavingHooks, the weaver bundle (org.apache.aries.spifly.dynamic.bundle in
the SPI Fly case) needs to be active before any bundles that need to be
dynamically woven. OSGi Start Levels can provide a mechanism to control
this.

Does the dynamic weaving bundle use the OSGi API to register a weaving hook
as Peter mentioned? If so how can I access it and make my UI code depend on
that service to guarantee that the weaving hook service will be started
before my UI bundle?

Kind regards,

Elliot



On Fri, Dec 9, 2016 at 3:26 AM, Peter Kriens <peter.kri...@aqute.biz> wrote:

> 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>
> 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) to isolate
> the code that integrates the SPI Fly dynamic weaving. The latest commit on
> this project allows the dynamic weaving feature to be

Re: [osgi-dev] Strange issue with enRoute and Aries SPI Fly.

2016-12-09 Thread Peter Kriens
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..

Re: [osgi-dev] Strange issue with enRoute and Aries SPI Fly.

2016-12-08 Thread Christian Schneider

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

Re: [osgi-dev] Strange issue with enRoute and Aries SPI Fly.

2016-12-08 Thread Peter Kriens
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  
> 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 
>  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 
> ) 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  > 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 > > 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
>> 

Re: [osgi-dev] Strange issue with enRoute and Aries SPI Fly.

2016-12-07 Thread Elliot Huntington
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  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) 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  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 
> 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
> 

Re: [osgi-dev] Strange issue with enRoute and Aries SPI Fly.

2016-12-06 Thread Peter Kriens
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  
> 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="com.github.axiopisty.plarpebu.mediaplayer.api.MediaPlayer"
> Require-Capability = osgi.ee ;filter:="(&(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
> 

Re: [osgi-dev] Strange issue with enRoute and Aries SPI Fly.

2016-12-05 Thread Elliot Huntington
@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="com.github.axiopisty.plarpebu.mediaplayer.api.MediaPlayer"
Require-Capability = osgi.ee;filter:="(&(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.(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

Re: [osgi-dev] Strange issue with enRoute and Aries SPI Fly.

2016-12-05 Thread BJ Hargrave
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 HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Elliot Huntington Sent by: osgi-dev-boun...@mail.osgi.orgTo: OSGi Developer Mail List 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. This project has 5 enRoute modules:

JavaFX APIJavaFX API ProviderMedia Player APIMedia Player API ProviderApplication
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 Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
 

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev