[osgi-dev] OSGi Logging

2018-07-10 Thread Paul F Fraser via osgi-dev
Somewhere in an Eclipsecon video or some other source I came across some info on the new logging 
setup which I cannot find now. It might have been David and Carsten, but not sure.


The spec will be most valuable once I understand what is going on!

Anyway, to the point, is there an approach which has a console output like 
slf4j.simple. If so, how?

The only references I have found so far uses either Karaf and/or pax logging.

Mike Francis asked for suggestions for examples and I think logging would be a good one. It is 
generally overlooked in most presentations.


Paul Fraser


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


Re: [osgi-dev] Service ranking usage

2018-07-10 Thread Alain Picard via osgi-dev
How beautiful

g! setting to: CoreUtils--SomeService
activate:CoreUtils--SomeService
Unsetting service
setting to: ExtUtils--SomeService
activate:ExtUtils--SomeService


On Tue, Jul 10, 2018 at 5:33 PM Neil Bartlett  wrote:

> Right. If you used static+greedy then you would see the deactivate and
> activate methods called. This is because static would force DS to create a
> new component instance.
>
> Neil
>
> On Tue, 10 Jul 2018 at 22:31, Alain Picard  wrote:
>
>> Neil,
>>
>> As you saw I was on the right track but what I failed to realize is that
>> this doesn't trigger a new call to the @Activate method. I changed the
>> reference to use a bind/unbind method pair and a sysout in there shows
>> exactly the pattern that you described.
>>
>> Thanks
>> Alain
>>
>>
>> On Tue, Jul 10, 2018 at 5:13 PM Neil Bartlett 
>> wrote:
>>
>>> Your reference to service ICoreUtils in Example is mandatory, static and
>>> reluctant. This means that whichever service it first binds to, it will
>>> hold for as long as possible.
>>>
>>> Since the lower ranked service is published by a bundle with a lower ID,
>>> it is probably published first. So that’s the one you will get.
>>>
>>> If you uncomment the dynamic+greedy setting in Example I expect you will
>>> see the component briefly bind to the lower ranked service and then re-bind
>>> to the higher ranked service. This is part of the definition of greedy.
>>>
>>> Neil
>>>
>>> On Tue, 10 Jul 2018 at 22:05, Alain Picard via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
 As part of DS enabling a lot of our code, I am testing how to compose
 services after finding out that reference annotations are not inherited.
 But I am facing a much more basic issue dealing with service ranking.

 Made a trivial example of an interface with one  method and 2
 implementation and with one having a higher service ranking. I always get
 the same one to execute and not the one I expect (only get the other if I
 comment the @Component reference on CoreUtils and then it refreshes with
 ExtUtils.

 What is wrong with my approach.
 [image: image.png]

 ___
 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

Re: [osgi-dev] Service ranking usage

2018-07-10 Thread Neil Bartlett via osgi-dev
Right. If you used static+greedy then you would see the deactivate and
activate methods called. This is because static would force DS to create a
new component instance.

Neil

On Tue, 10 Jul 2018 at 22:31, Alain Picard  wrote:

> Neil,
>
> As you saw I was on the right track but what I failed to realize is that
> this doesn't trigger a new call to the @Activate method. I changed the
> reference to use a bind/unbind method pair and a sysout in there shows
> exactly the pattern that you described.
>
> Thanks
> Alain
>
>
> On Tue, Jul 10, 2018 at 5:13 PM Neil Bartlett 
> wrote:
>
>> Your reference to service ICoreUtils in Example is mandatory, static and
>> reluctant. This means that whichever service it first binds to, it will
>> hold for as long as possible.
>>
>> Since the lower ranked service is published by a bundle with a lower ID,
>> it is probably published first. So that’s the one you will get.
>>
>> If you uncomment the dynamic+greedy setting in Example I expect you will
>> see the component briefly bind to the lower ranked service and then re-bind
>> to the higher ranked service. This is part of the definition of greedy.
>>
>> Neil
>>
>> On Tue, 10 Jul 2018 at 22:05, Alain Picard via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> As part of DS enabling a lot of our code, I am testing how to compose
>>> services after finding out that reference annotations are not inherited.
>>> But I am facing a much more basic issue dealing with service ranking.
>>>
>>> Made a trivial example of an interface with one  method and 2
>>> implementation and with one having a higher service ranking. I always get
>>> the same one to execute and not the one I expect (only get the other if I
>>> comment the @Component reference on CoreUtils and then it refreshes with
>>> ExtUtils.
>>>
>>> What is wrong with my approach.
>>> [image: image.png]
>>>
>>> ___
>>> 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

Re: [osgi-dev] Service ranking usage

2018-07-10 Thread Alain Picard via osgi-dev
Neil,

As you saw I was on the right track but what I failed to realize is that
this doesn't trigger a new call to the @Activate method. I changed the
reference to use a bind/unbind method pair and a sysout in there shows
exactly the pattern that you described.

Thanks
Alain


On Tue, Jul 10, 2018 at 5:13 PM Neil Bartlett  wrote:

> Your reference to service ICoreUtils in Example is mandatory, static and
> reluctant. This means that whichever service it first binds to, it will
> hold for as long as possible.
>
> Since the lower ranked service is published by a bundle with a lower ID,
> it is probably published first. So that’s the one you will get.
>
> If you uncomment the dynamic+greedy setting in Example I expect you will
> see the component briefly bind to the lower ranked service and then re-bind
> to the higher ranked service. This is part of the definition of greedy.
>
> Neil
>
> On Tue, 10 Jul 2018 at 22:05, Alain Picard via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> As part of DS enabling a lot of our code, I am testing how to compose
>> services after finding out that reference annotations are not inherited.
>> But I am facing a much more basic issue dealing with service ranking.
>>
>> Made a trivial example of an interface with one  method and 2
>> implementation and with one having a higher service ranking. I always get
>> the same one to execute and not the one I expect (only get the other if I
>> comment the @Component reference on CoreUtils and then it refreshes with
>> ExtUtils.
>>
>> What is wrong with my approach.
>> [image: image.png]
>>
>> ___
>> 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

Re: [osgi-dev] Service ranking usage

2018-07-10 Thread Neil Bartlett via osgi-dev
Your reference to service ICoreUtils in Example is mandatory, static and
reluctant. This means that whichever service it first binds to, it will
hold for as long as possible.

Since the lower ranked service is published by a bundle with a lower ID, it
is probably published first. So that’s the one you will get.

If you uncomment the dynamic+greedy setting in Example I expect you will
see the component briefly bind to the lower ranked service and then re-bind
to the higher ranked service. This is part of the definition of greedy.

Neil

On Tue, 10 Jul 2018 at 22:05, Alain Picard via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> As part of DS enabling a lot of our code, I am testing how to compose
> services after finding out that reference annotations are not inherited.
> But I am facing a much more basic issue dealing with service ranking.
>
> Made a trivial example of an interface with one  method and 2
> implementation and with one having a higher service ranking. I always get
> the same one to execute and not the one I expect (only get the other if I
> comment the @Component reference on CoreUtils and then it refreshes with
> ExtUtils.
>
> What is wrong with my approach.
> [image: image.png]
>
> ___
> 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

[osgi-dev] Service ranking usage

2018-07-10 Thread Alain Picard via osgi-dev
As part of DS enabling a lot of our code, I am testing how to compose
services after finding out that reference annotations are not inherited.
But I am facing a much more basic issue dealing with service ranking.

Made a trivial example of an interface with one  method and 2
implementation and with one having a higher service ranking. I always get
the same one to execute and not the one I expect (only get the other if I
comment the @Component reference on CoreUtils and then it refreshes with
ExtUtils.

What is wrong with my approach.
[image: image.png]
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev