You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Imóveis Nacionais <im...@gmail.com> on 2013/02/14 17:50:31 UTC
ServiceListener influenced by import directive: could someone confirm this?
Hi all, me again…
Suppose you have the following OSGi bundles and the related exposed
services:
BundleService1 -> exports service 1 and interface for service 1
BundleService2 -> exports service 2 and interface for service 2
Now I want to write the Bundle3 which will use both Service1 and Service2
(for now, just service1).
So, Bundle3 (activator class) implements BundleActivator and
ServiceListener.
On start() I do: context.addServiceListener(this);
On the serviceChanged() method I simply have a print to console.
This works with no problem.
------------------------------------------------------------------------------------------------------------
Suppose now that you want to call service1 from serviceChanged method (just
an example!):
To call service1 I need to add dependence to pom.xml for BundleService1 in
order to get reference and cast the reference to the service1 interface.
Then, on the activator class I need to put an import for the service1
interface. Then I get the reference, evaluate the property, cast it to
service1 and call the service1.
Now, testing this stuff:
I install Bundle3 and start it.
I install BundleService1 and start it. Nothing happens on bundle3
serviceChanged!!!
Then I install BundleService2 and start it. The bundle3 serviceChanged is
called!!!
If I install and start any other bundles serviceChanged is always called,
except for BundleService1!
If I remove the import directive from Bundle3 (while the POM dependence
remains) and comment the related code, Bundle3 serviceChanged is called for
BundleService1!
My conclusion is that, the ServiceListener only works for those bundles
that have no “connection” (import) with Bundle3. Is this true?
If this is true, how can I get the reference and cast to the service in
order to call it without using imports?
Note: In an attempt to solve the problem I did the following: in the
serviceChanged I called another bundle3 class giving it the event in order
to remove the import from activator class, and move it to the other class.
But serviceChanged did not detects the Service1 too. It seems that if the
(client) bundle project has an import for some service bundles those
bundles are not “detected” in the serviceChanged method.
Thank you
Alex
Re: ServiceListener influenced by import directive: could someone
confirm this?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
When you update and uninstall bundles, they aren't really fully updated
and uninstalled until you perform a refresh. This makes is possible for
old stale versions of packages to hang around, which can lead to
situations like you have witnessed.
In general, unless you really know what you are doing you should always
perform a refresh after uninstalling or updating bundles.
-> richard
On 2/14/13 20:40 , Imóveis Nacionais wrote:
> Yes, its that!!
>
> Using refresh, the framework do not allow the launching of the vigia bundle
> and then the service because vigia depends on service! Without refresh,
> maybe vigia is using a zombie service.
>
> Now, I do stop to the service and start and these events are now reported!
> How sad...
>
> Thanks a lot karl and Richard ...
>
> Alex
>
>
>
> On Fri, Feb 15, 2013 at 1:03 AM, Karl Pauls <ka...@gmail.com> wrote:
>
>> try to call:
>>
>> refresh
>>
>> after each uninstall
>>
>> regards,
>>
>> Karl
>>
>>
>> On Fri, Feb 15, 2013 at 1:36 AM, Imóveis Nacionais <
>> imoveisnacionais@gmail.com> wrote:
>>
>>> Hi Richard, here it is...
>>>
>>>
>>>
>>> Use the first zip for this first test case.
>>>
>>>
>>>
>>> vigia-1.0.jar has just print instructions in the serviceChanged (source
>>> code is also in attachment)
>>>
>>> MyOSGi-1.0-SNAPSHOT.jar is a sample service bundle
>>>
>>> MyBundleServer-1.0-SNAPSHOT.jar is another sample service bundle
>>>
>>> Test this stuff like this :
>>>
>>>
>>> g! install file:/C:/PROJS/OSGi/felix-framework-4.0.3/vigia-1.0.jar
>>>
>>> Bundle ID: 86
>>>
>>> g! start 86
>>>
>>> Client bundle initializing on start method...
>>>
>>> g!
>>>
>>>
>>>
>>> then:
>>>
>>>
>>>
>>> g! install
>>> file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyOSGi-1.0-SNAPSHOT.jar
>>>
>>> Bundle ID: 88
>>>
>>> g! start 88
>>>
>>> Server bundle start method initializing
>>>
>>>
>>>
>>>
>>>
>>> serviceChanged called...
>>>
>>> Gestting description...
>>>
>>> ->This an service impl object
>>>
>>>
>>>
>>>
>>>
>>> O serviþo foi registado! //Means service was registered, in
>>> english
>>>
>>> g!
>>>
>>>
>>>
>>> Then
>>>
>>>
>>>
>>> g! install
>>> file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyBundleServer-1.0-SNAPSHOT
>>>
>>> .jar
>>>
>>> Bundle ID: 89
>>>
>>> g! start 89
>>>
>>> Server bundle start method initializing
>>>
>>>
>>>
>>>
>>>
>>> serviceChanged called...
>>>
>>> Gestting description...
>>>
>>> ->GET_NUMBER_SERVICE
>>>
>>>
>>>
>>>
>>>
>>> O serviþo foi registado!
>>>
>>> g!
>>>
>>>
>>>
>>>
>>>
>>> As you can see the 'global service' listener works well.
>>>
>>>
>>>
>>>
>>>
>>> Now do the uninstallation of the 3 bundles:
>>>
>>>
>>>
>>> g! uninstall 89
>>>
>>>
>>>
>>>
>>>
>>> serviceChanged called...
>>>
>>> Gestting description...
>>>
>>> ->GET_NUMBER_SERVICE
>>>
>>>
>>>
>>>
>>>
>>> g! uninstall 88
>>>
>>> Goodbye OSGi World
>>>
>>>
>>>
>>>
>>>
>>> serviceChanged called...
>>>
>>> Gestting description...
>>>
>>> ->This an service impl object
>>>
>>>
>>>
>>>
>>>
>>> g! uninstall 86
>>>
>>> g!
>>>
>>>
>>>
>>>
>>>
>>> Now use the second zip file. In this zip file, vigia-1.0.jar has print
>>> instructions in the serviceChanged but also an attempt to get a reference
>>> for a service and a call to the service (source code is also in
>> attachment
>>> for vigia and for the project where interface is exported)
>>>
>>>
>>> g! install file:/C:/PROJS/OSGi/felix-framework-4.0.3/vigia-1.0.jar
>>>
>>> Bundle ID: 90
>>>
>>> g! start 90
>>>
>>> Client bundle initializing on start method...
>>>
>>>
>>>
>>> Then
>>>
>>>
>>>
>>> g! install
>>> file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyOSGi-1.0-SNAPSHOT.jar
>>>
>>> Bundle ID: 91
>>>
>>> g! start 91
>>>
>>> Server bundle start method initializing
>>>
>>>
>>>
>>>
>>>
>>> serviceChanged called...
>>> ->CALLED
>>>
>>> Gestting description...
>>>
>>> ->This an service impl object
>>>
>>>
>>>
>>>
>>>
>>> O serviþo foi registado!
>>>
>>> g!
>>>
>>>
>>>
>>>
>>>
>>> and then:
>>>
>>> g! install
>>> file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyBundleServer-1.0-SNAPSHOT
>>>
>>> .jar
>>>
>>> Bundle ID: 94
>>> -> serviceChanged NOT CALLED!
>>>
>>> g! start 94
>>>
>>> Server bundle start method initializing
>>>
>>> O serviþo foi registado!
>>>
>>>
>>>
>>>
>>>
>>> As you see the serviceChanged was not called this time. Even if you
>>> remove all the code from serviceChanged and let only the prints and the
>>> import, it is not called either. If you comment the code in
>> serviceChanged
>>> (let only the prints) and comment the import statement, then the
>>> serviceChanged is called.
>>>
>>>
>>>
>>> I am trying to understand this behavior... Thanks a lot
>>>
>>>
>>>
>>> Alex
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Feb 14, 2013 at 11:44 PM, Richard S. Hall <heavy@ungoverned.org
>>> wrote:
>>>
>>>> If you want to create me a simple example of two bundles (one client and
>>>> one server) where the client can't see the other, I'll take a look at it
>>>> and try to explain what is going on...from your description, I'm still
>> not
>>>> sure what precisely is triggering the situation.
>>>>
>>>> -> richard
>>>>
>>>>
>>>> On 2/14/13 6:40 PM, Imóveis Nacionais wrote:
>>>>
>>>>> My "AllServiceListener" takes place when serviceChanged( ) has just a
>>>>> print
>>>>> to console. In this situation all osgi services fire the
>> serviceChanged()
>>>>> method.
>>>>>
>>>>> The problem appears when I build a 'special listener' (for example for
>>>>> BundleService1 as i said) in order to fill an handle to the service to
>> be
>>>>> called later. In this situation, to declare a variable of service1
>>>>> interface to save the service object reference, I have to put the
>> import
>>>>> statement and the special listener does not detects service1 anymore,
>>>>> only
>>>>> service 2,3, 4,etc...
>>>>>
>>>>> May be i am using ServiceListener in a worng way, but it is logic for
>> me
>>>>> to
>>>>> get the pointer to the service when it is up...
>>>>>
>>>>> Thanks
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 14, 2013 at 6:55 PM, Richard S. Hall <heavy@ungoverned.org
>>>>>> wrote:
>>>>> The OSGi framework attempts to deliver service events that are usable
>> by
>>>>>> your bundle (i.e., class compatible), so by having or not having
>> imports
>>>>>> and depending on the provider of your imports you may or may not see
>>>>>> events
>>>>>> if the framework thinks they might cause you class cast problems.
>>>>>>
>>>>>> If you want to test this out, you can implement *AllServiceListener*
>> as
>>>>>> a
>>>>>>
>>>>>> test to see if you get all events; this listener will get all service
>>>>>> event
>>>>>> irrespective of whether they might cause class cast exceptions.
>>>>>>
>>>>>> Generally, you only want to use an "all" listener if you are
>> monitoring
>>>>>> an
>>>>>> entire system, but not really interacting with services (or are using
>>>>>> reflection to do so). Normally, you only want the framework sending
>>>>>> events
>>>>>> to service you can access without a class cast exception using the
>>>>>> normal
>>>>>> ServiceListener.
>>>>>>
>>>>>> -> richard
>>>>>>
>>>>>> p.s. For completeness, here a description of what the Felix framework
>>>>>> tries to do from ServiceRegistrationImpl.java:
>>>>>>
>>>>>> // There are four situations that may occur here:
>>>>>> // 1. Neither the requester, nor provider have wires
>> for
>>>>>> the
>>>>>> package.
>>>>>> // 2. The requester does not have a wire for the
>> package.
>>>>>> // 3. The provider does not have a wire for the
>> package.
>>>>>> // 4. Both the requester and provider have a wire for
>> the
>>>>>> package.
>>>>>> // For case 1, if the requester does not have access to
>> the
>>>>>> class at
>>>>>> // all, we assume it is using reflection and do not
>>>>>> filter. If
>>>>>> the
>>>>>> // requester does have access to the class, then we make
>>>>>> sure
>>>>>> it is
>>>>>> // the same class as the service. For case 2, we do not
>>>>>> filter
>>>>>> if the
>>>>>> // requester is the exporter of the package to which the
>>>>>> provider of
>>>>>> // the service is wired. Otherwise, as in case 1, if the
>>>>>> requester
>>>>>> // does not have access to the class at all, we do not
>>>>>> filter,
>>>>>> but if
>>>>>> // it does have access we check if it is the same class
>>>>>> accessible to
>>>>>> // the providing revision. For case 3, the provider will
>>>>>> not
>>>>>> have a wire
>>>>>> // if it is exporting the package, so we determine if the
>>>>>> requester
>>>>>> // is wired to it or somehow using the same class. For
>>>>>> case 4,
>>>>>> we
>>>>>> // simply compare the exporting revisions from the
>> package
>>>>>> wiring to
>>>>>> // determine if we need to filter the service reference.
>>>>>>
>>>>>>
>>>>>> On 2/14/13 11:50 , Imóveis Nacionais wrote:
>>>>>>
>>>>>> Hi all, me again…
>>>>>>>
>>>>>>> Suppose you have the following OSGi bundles and the related exposed
>>>>>>> services:
>>>>>>>
>>>>>>> BundleService1 -> exports service 1 and interface for service 1
>>>>>>>
>>>>>>> BundleService2 -> exports service 2 and interface for service 2
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Now I want to write the Bundle3 which will use both Service1 and
>>>>>>> Service2
>>>>>>> (for now, just service1).
>>>>>>>
>>>>>>> So, Bundle3 (activator class) implements BundleActivator and
>>>>>>> ServiceListener.
>>>>>>>
>>>>>>> On start() I do: context.addServiceListener(****this);
>>>>>>>
>>>>>>>
>>>>>>> On the serviceChanged() method I simply have a print to console.
>>>>>>>
>>>>>>> This works with no problem.
>>>>>>>
>>>>>>> ------------------------------****----------------------------**--**
>>>>>>> ------------------------------****------------------
>>>>>>>
>>>>>>>
>>>>>>> Suppose now that you want to call service1 from serviceChanged method
>>>>>>> (just
>>>>>>> an example!):
>>>>>>>
>>>>>>> To call service1 I need to add dependence to pom.xml for
>>>>>>> BundleService1 in
>>>>>>> order to get reference and cast the reference to the service1
>>>>>>> interface.
>>>>>>>
>>>>>>> Then, on the activator class I need to put an import for the service1
>>>>>>> interface. Then I get the reference, evaluate the property, cast it
>> to
>>>>>>> service1 and call the service1.
>>>>>>>
>>>>>>>
>>>>>>> Now, testing this stuff:
>>>>>>>
>>>>>>> I install Bundle3 and start it.
>>>>>>>
>>>>>>> I install BundleService1 and start it. Nothing happens on bundle3
>>>>>>> serviceChanged!!!
>>>>>>>
>>>>>>> Then I install BundleService2 and start it. The bundle3
>> serviceChanged
>>>>>>> is
>>>>>>> called!!!
>>>>>>>
>>>>>>>
>>>>>>> If I install and start any other bundles serviceChanged is always
>>>>>>> called,
>>>>>>> except for BundleService1!
>>>>>>>
>>>>>>> If I remove the import directive from Bundle3 (while the POM
>> dependence
>>>>>>> remains) and comment the related code, Bundle3 serviceChanged is
>> called
>>>>>>> for
>>>>>>> BundleService1!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My conclusion is that, the ServiceListener only works for those
>> bundles
>>>>>>> that have no “connection” (import) with Bundle3. Is this true?
>>>>>>>
>>>>>>> If this is true, how can I get the reference and cast to the service
>> in
>>>>>>> order to call it without using imports?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Note: In an attempt to solve the problem I did the following: in the
>>>>>>> serviceChanged I called another bundle3 class giving it the event in
>>>>>>> order
>>>>>>> to remove the import from activator class, and move it to the other
>>>>>>> class.
>>>>>>> But serviceChanged did not detects the Service1 too. It seems that if
>>>>>>> the
>>>>>>> (client) bundle project has an import for some service bundles those
>>>>>>> bundles are not “detected” in the serviceChanged method.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thank you
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------****----------------------------**
>>>>>> --**---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apac**he.org<
>> http://apache.org>
>>>>>> <users-unsubscribe@**felix.apache.org<
>> users-unsubscribe@felix.apache.org>
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>
>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<
>> users-unsubscribe@felix.apache.org>
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>> http://twitter.com/karlpauls
>> http://www.linkedin.com/in/karlpauls
>> https://profiles.google.com/karlpauls
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ServiceListener influenced by import directive: could someone
confirm this?
Posted by Imóveis Nacionais <im...@gmail.com>.
Yes, its that!!
Using refresh, the framework do not allow the launching of the vigia bundle
and then the service because vigia depends on service! Without refresh,
maybe vigia is using a zombie service.
Now, I do stop to the service and start and these events are now reported!
How sad...
Thanks a lot karl and Richard ...
Alex
On Fri, Feb 15, 2013 at 1:03 AM, Karl Pauls <ka...@gmail.com> wrote:
> try to call:
>
> refresh
>
> after each uninstall
>
> regards,
>
> Karl
>
>
> On Fri, Feb 15, 2013 at 1:36 AM, Imóveis Nacionais <
> imoveisnacionais@gmail.com> wrote:
>
> > Hi Richard, here it is...
> >
> >
> >
> > Use the first zip for this first test case.
> >
> >
> >
> > vigia-1.0.jar has just print instructions in the serviceChanged (source
> > code is also in attachment)
> >
> > MyOSGi-1.0-SNAPSHOT.jar is a sample service bundle
> >
> > MyBundleServer-1.0-SNAPSHOT.jar is another sample service bundle
> >
> > Test this stuff like this :
> >
> >
> > g! install file:/C:/PROJS/OSGi/felix-framework-4.0.3/vigia-1.0.jar
> >
> > Bundle ID: 86
> >
> > g! start 86
> >
> > Client bundle initializing on start method...
> >
> > g!
> >
> >
> >
> > then:
> >
> >
> >
> > g! install
> > file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyOSGi-1.0-SNAPSHOT.jar
> >
> > Bundle ID: 88
> >
> > g! start 88
> >
> > Server bundle start method initializing
> >
> >
> >
> >
> >
> > serviceChanged called...
> >
> > Gestting description...
> >
> > ->This an service impl object
> >
> >
> >
> >
> >
> > O serviþo foi registado! //Means service was registered, in
> > english
> >
> > g!
> >
> >
> >
> > Then
> >
> >
> >
> > g! install
> > file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyBundleServer-1.0-SNAPSHOT
> >
> > .jar
> >
> > Bundle ID: 89
> >
> > g! start 89
> >
> > Server bundle start method initializing
> >
> >
> >
> >
> >
> > serviceChanged called...
> >
> > Gestting description...
> >
> > ->GET_NUMBER_SERVICE
> >
> >
> >
> >
> >
> > O serviþo foi registado!
> >
> > g!
> >
> >
> >
> >
> >
> > As you can see the 'global service' listener works well.
> >
> >
> >
> >
> >
> > Now do the uninstallation of the 3 bundles:
> >
> >
> >
> > g! uninstall 89
> >
> >
> >
> >
> >
> > serviceChanged called...
> >
> > Gestting description...
> >
> > ->GET_NUMBER_SERVICE
> >
> >
> >
> >
> >
> > g! uninstall 88
> >
> > Goodbye OSGi World
> >
> >
> >
> >
> >
> > serviceChanged called...
> >
> > Gestting description...
> >
> > ->This an service impl object
> >
> >
> >
> >
> >
> > g! uninstall 86
> >
> > g!
> >
> >
> >
> >
> >
> > Now use the second zip file. In this zip file, vigia-1.0.jar has print
> > instructions in the serviceChanged but also an attempt to get a reference
> > for a service and a call to the service (source code is also in
> attachment
> > for vigia and for the project where interface is exported)
> >
> >
> > g! install file:/C:/PROJS/OSGi/felix-framework-4.0.3/vigia-1.0.jar
> >
> > Bundle ID: 90
> >
> > g! start 90
> >
> > Client bundle initializing on start method...
> >
> >
> >
> > Then
> >
> >
> >
> > g! install
> > file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyOSGi-1.0-SNAPSHOT.jar
> >
> > Bundle ID: 91
> >
> > g! start 91
> >
> > Server bundle start method initializing
> >
> >
> >
> >
> >
> > serviceChanged called...
> > ->CALLED
> >
> > Gestting description...
> >
> > ->This an service impl object
> >
> >
> >
> >
> >
> > O serviþo foi registado!
> >
> > g!
> >
> >
> >
> >
> >
> > and then:
> >
> > g! install
> > file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyBundleServer-1.0-SNAPSHOT
> >
> > .jar
> >
> > Bundle ID: 94
> > -> serviceChanged NOT CALLED!
> >
> > g! start 94
> >
> > Server bundle start method initializing
> >
> > O serviþo foi registado!
> >
> >
> >
> >
> >
> > As you see the serviceChanged was not called this time. Even if you
> > remove all the code from serviceChanged and let only the prints and the
> > import, it is not called either. If you comment the code in
> serviceChanged
> > (let only the prints) and comment the import statement, then the
> > serviceChanged is called.
> >
> >
> >
> > I am trying to understand this behavior... Thanks a lot
> >
> >
> >
> > Alex
> >
> >
> >
> >
> >
> >
> > On Thu, Feb 14, 2013 at 11:44 PM, Richard S. Hall <heavy@ungoverned.org
> >wrote:
> >
> >> If you want to create me a simple example of two bundles (one client and
> >> one server) where the client can't see the other, I'll take a look at it
> >> and try to explain what is going on...from your description, I'm still
> not
> >> sure what precisely is triggering the situation.
> >>
> >> -> richard
> >>
> >>
> >> On 2/14/13 6:40 PM, Imóveis Nacionais wrote:
> >>
> >>> My "AllServiceListener" takes place when serviceChanged( ) has just a
> >>> print
> >>> to console. In this situation all osgi services fire the
> serviceChanged()
> >>> method.
> >>>
> >>> The problem appears when I build a 'special listener' (for example for
> >>> BundleService1 as i said) in order to fill an handle to the service to
> be
> >>> called later. In this situation, to declare a variable of service1
> >>> interface to save the service object reference, I have to put the
> import
> >>> statement and the special listener does not detects service1 anymore,
> >>> only
> >>> service 2,3, 4,etc...
> >>>
> >>> May be i am using ServiceListener in a worng way, but it is logic for
> me
> >>> to
> >>> get the pointer to the service when it is up...
> >>>
> >>> Thanks
> >>>
> >>> Alex
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Feb 14, 2013 at 6:55 PM, Richard S. Hall <heavy@ungoverned.org
> >>> >wrote:
> >>>
> >>> The OSGi framework attempts to deliver service events that are usable
> by
> >>>> your bundle (i.e., class compatible), so by having or not having
> imports
> >>>> and depending on the provider of your imports you may or may not see
> >>>> events
> >>>> if the framework thinks they might cause you class cast problems.
> >>>>
> >>>> If you want to test this out, you can implement *AllServiceListener*
> as
> >>>> a
> >>>>
> >>>> test to see if you get all events; this listener will get all service
> >>>> event
> >>>> irrespective of whether they might cause class cast exceptions.
> >>>>
> >>>> Generally, you only want to use an "all" listener if you are
> monitoring
> >>>> an
> >>>> entire system, but not really interacting with services (or are using
> >>>> reflection to do so). Normally, you only want the framework sending
> >>>> events
> >>>> to service you can access without a class cast exception using the
> >>>> normal
> >>>> ServiceListener.
> >>>>
> >>>> -> richard
> >>>>
> >>>> p.s. For completeness, here a description of what the Felix framework
> >>>> tries to do from ServiceRegistrationImpl.java:
> >>>>
> >>>> // There are four situations that may occur here:
> >>>> // 1. Neither the requester, nor provider have wires
> for
> >>>> the
> >>>> package.
> >>>> // 2. The requester does not have a wire for the
> package.
> >>>> // 3. The provider does not have a wire for the
> package.
> >>>> // 4. Both the requester and provider have a wire for
> the
> >>>> package.
> >>>> // For case 1, if the requester does not have access to
> the
> >>>> class at
> >>>> // all, we assume it is using reflection and do not
> >>>> filter. If
> >>>> the
> >>>> // requester does have access to the class, then we make
> >>>> sure
> >>>> it is
> >>>> // the same class as the service. For case 2, we do not
> >>>> filter
> >>>> if the
> >>>> // requester is the exporter of the package to which the
> >>>> provider of
> >>>> // the service is wired. Otherwise, as in case 1, if the
> >>>> requester
> >>>> // does not have access to the class at all, we do not
> >>>> filter,
> >>>> but if
> >>>> // it does have access we check if it is the same class
> >>>> accessible to
> >>>> // the providing revision. For case 3, the provider will
> >>>> not
> >>>> have a wire
> >>>> // if it is exporting the package, so we determine if the
> >>>> requester
> >>>> // is wired to it or somehow using the same class. For
> >>>> case 4,
> >>>> we
> >>>> // simply compare the exporting revisions from the
> package
> >>>> wiring to
> >>>> // determine if we need to filter the service reference.
> >>>>
> >>>>
> >>>> On 2/14/13 11:50 , Imóveis Nacionais wrote:
> >>>>
> >>>> Hi all, me again…
> >>>>>
> >>>>>
> >>>>> Suppose you have the following OSGi bundles and the related exposed
> >>>>> services:
> >>>>>
> >>>>> BundleService1 -> exports service 1 and interface for service 1
> >>>>>
> >>>>> BundleService2 -> exports service 2 and interface for service 2
> >>>>>
> >>>>>
> >>>>>
> >>>>> Now I want to write the Bundle3 which will use both Service1 and
> >>>>> Service2
> >>>>> (for now, just service1).
> >>>>>
> >>>>> So, Bundle3 (activator class) implements BundleActivator and
> >>>>> ServiceListener.
> >>>>>
> >>>>> On start() I do: context.addServiceListener(****this);
> >>>>>
> >>>>>
> >>>>> On the serviceChanged() method I simply have a print to console.
> >>>>>
> >>>>> This works with no problem.
> >>>>>
> >>>>> ------------------------------****----------------------------**--**
> >>>>> ------------------------------****------------------
> >>>>>
> >>>>>
> >>>>> Suppose now that you want to call service1 from serviceChanged method
> >>>>> (just
> >>>>> an example!):
> >>>>>
> >>>>> To call service1 I need to add dependence to pom.xml for
> >>>>> BundleService1 in
> >>>>> order to get reference and cast the reference to the service1
> >>>>> interface.
> >>>>>
> >>>>> Then, on the activator class I need to put an import for the service1
> >>>>> interface. Then I get the reference, evaluate the property, cast it
> to
> >>>>> service1 and call the service1.
> >>>>>
> >>>>>
> >>>>> Now, testing this stuff:
> >>>>>
> >>>>> I install Bundle3 and start it.
> >>>>>
> >>>>> I install BundleService1 and start it. Nothing happens on bundle3
> >>>>> serviceChanged!!!
> >>>>>
> >>>>> Then I install BundleService2 and start it. The bundle3
> serviceChanged
> >>>>> is
> >>>>> called!!!
> >>>>>
> >>>>>
> >>>>> If I install and start any other bundles serviceChanged is always
> >>>>> called,
> >>>>> except for BundleService1!
> >>>>>
> >>>>> If I remove the import directive from Bundle3 (while the POM
> dependence
> >>>>> remains) and comment the related code, Bundle3 serviceChanged is
> called
> >>>>> for
> >>>>> BundleService1!
> >>>>>
> >>>>>
> >>>>>
> >>>>> My conclusion is that, the ServiceListener only works for those
> bundles
> >>>>> that have no “connection” (import) with Bundle3. Is this true?
> >>>>>
> >>>>> If this is true, how can I get the reference and cast to the service
> in
> >>>>> order to call it without using imports?
> >>>>>
> >>>>>
> >>>>>
> >>>>> Note: In an attempt to solve the problem I did the following: in the
> >>>>> serviceChanged I called another bundle3 class giving it the event in
> >>>>> order
> >>>>> to remove the import from activator class, and move it to the other
> >>>>> class.
> >>>>> But serviceChanged did not detects the Service1 too. It seems that if
> >>>>> the
> >>>>> (client) bundle project has an import for some service bundles those
> >>>>> bundles are not “detected” in the serviceChanged method.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thank you
> >>>>>
> >>>>> Alex
> >>>>>
> >>>>>
> >>>>> ------------------------------****----------------------------**
> >>>> --**---------
> >>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apac**he.org<
> http://apache.org>
> >>>> <users-unsubscribe@**felix.apache.org<
> users-unsubscribe@felix.apache.org>
> >>>> >
> >>>>
> >>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>
> >>>>
> >>>>
> >>
> >>
> ------------------------------**------------------------------**---------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<
> users-unsubscribe@felix.apache.org>
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
>
Re: ServiceListener influenced by import directive: could someone
confirm this?
Posted by Karl Pauls <ka...@gmail.com>.
try to call:
refresh
after each uninstall
regards,
Karl
On Fri, Feb 15, 2013 at 1:36 AM, Imóveis Nacionais <
imoveisnacionais@gmail.com> wrote:
> Hi Richard, here it is...
>
>
>
> Use the first zip for this first test case.
>
>
>
> vigia-1.0.jar has just print instructions in the serviceChanged (source
> code is also in attachment)
>
> MyOSGi-1.0-SNAPSHOT.jar is a sample service bundle
>
> MyBundleServer-1.0-SNAPSHOT.jar is another sample service bundle
>
> Test this stuff like this :
>
>
> g! install file:/C:/PROJS/OSGi/felix-framework-4.0.3/vigia-1.0.jar
>
> Bundle ID: 86
>
> g! start 86
>
> Client bundle initializing on start method...
>
> g!
>
>
>
> then:
>
>
>
> g! install
> file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyOSGi-1.0-SNAPSHOT.jar
>
> Bundle ID: 88
>
> g! start 88
>
> Server bundle start method initializing
>
>
>
>
>
> serviceChanged called...
>
> Gestting description...
>
> ->This an service impl object
>
>
>
>
>
> O serviþo foi registado! //Means service was registered, in
> english
>
> g!
>
>
>
> Then
>
>
>
> g! install
> file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyBundleServer-1.0-SNAPSHOT
>
> .jar
>
> Bundle ID: 89
>
> g! start 89
>
> Server bundle start method initializing
>
>
>
>
>
> serviceChanged called...
>
> Gestting description...
>
> ->GET_NUMBER_SERVICE
>
>
>
>
>
> O serviþo foi registado!
>
> g!
>
>
>
>
>
> As you can see the 'global service' listener works well.
>
>
>
>
>
> Now do the uninstallation of the 3 bundles:
>
>
>
> g! uninstall 89
>
>
>
>
>
> serviceChanged called...
>
> Gestting description...
>
> ->GET_NUMBER_SERVICE
>
>
>
>
>
> g! uninstall 88
>
> Goodbye OSGi World
>
>
>
>
>
> serviceChanged called...
>
> Gestting description...
>
> ->This an service impl object
>
>
>
>
>
> g! uninstall 86
>
> g!
>
>
>
>
>
> Now use the second zip file. In this zip file, vigia-1.0.jar has print
> instructions in the serviceChanged but also an attempt to get a reference
> for a service and a call to the service (source code is also in attachment
> for vigia and for the project where interface is exported)
>
>
> g! install file:/C:/PROJS/OSGi/felix-framework-4.0.3/vigia-1.0.jar
>
> Bundle ID: 90
>
> g! start 90
>
> Client bundle initializing on start method...
>
>
>
> Then
>
>
>
> g! install
> file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyOSGi-1.0-SNAPSHOT.jar
>
> Bundle ID: 91
>
> g! start 91
>
> Server bundle start method initializing
>
>
>
>
>
> serviceChanged called...
> ->CALLED
>
> Gestting description...
>
> ->This an service impl object
>
>
>
>
>
> O serviþo foi registado!
>
> g!
>
>
>
>
>
> and then:
>
> g! install
> file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyBundleServer-1.0-SNAPSHOT
>
> .jar
>
> Bundle ID: 94
> -> serviceChanged NOT CALLED!
>
> g! start 94
>
> Server bundle start method initializing
>
> O serviþo foi registado!
>
>
>
>
>
> As you see the serviceChanged was not called this time. Even if you
> remove all the code from serviceChanged and let only the prints and the
> import, it is not called either. If you comment the code in serviceChanged
> (let only the prints) and comment the import statement, then the
> serviceChanged is called.
>
>
>
> I am trying to understand this behavior... Thanks a lot
>
>
>
> Alex
>
>
>
>
>
>
> On Thu, Feb 14, 2013 at 11:44 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> If you want to create me a simple example of two bundles (one client and
>> one server) where the client can't see the other, I'll take a look at it
>> and try to explain what is going on...from your description, I'm still not
>> sure what precisely is triggering the situation.
>>
>> -> richard
>>
>>
>> On 2/14/13 6:40 PM, Imóveis Nacionais wrote:
>>
>>> My "AllServiceListener" takes place when serviceChanged( ) has just a
>>> print
>>> to console. In this situation all osgi services fire the serviceChanged()
>>> method.
>>>
>>> The problem appears when I build a 'special listener' (for example for
>>> BundleService1 as i said) in order to fill an handle to the service to be
>>> called later. In this situation, to declare a variable of service1
>>> interface to save the service object reference, I have to put the import
>>> statement and the special listener does not detects service1 anymore,
>>> only
>>> service 2,3, 4,etc...
>>>
>>> May be i am using ServiceListener in a worng way, but it is logic for me
>>> to
>>> get the pointer to the service when it is up...
>>>
>>> Thanks
>>>
>>> Alex
>>>
>>>
>>>
>>>
>>> On Thu, Feb 14, 2013 at 6:55 PM, Richard S. Hall <heavy@ungoverned.org
>>> >wrote:
>>>
>>> The OSGi framework attempts to deliver service events that are usable by
>>>> your bundle (i.e., class compatible), so by having or not having imports
>>>> and depending on the provider of your imports you may or may not see
>>>> events
>>>> if the framework thinks they might cause you class cast problems.
>>>>
>>>> If you want to test this out, you can implement *AllServiceListener* as
>>>> a
>>>>
>>>> test to see if you get all events; this listener will get all service
>>>> event
>>>> irrespective of whether they might cause class cast exceptions.
>>>>
>>>> Generally, you only want to use an "all" listener if you are monitoring
>>>> an
>>>> entire system, but not really interacting with services (or are using
>>>> reflection to do so). Normally, you only want the framework sending
>>>> events
>>>> to service you can access without a class cast exception using the
>>>> normal
>>>> ServiceListener.
>>>>
>>>> -> richard
>>>>
>>>> p.s. For completeness, here a description of what the Felix framework
>>>> tries to do from ServiceRegistrationImpl.java:
>>>>
>>>> // There are four situations that may occur here:
>>>> // 1. Neither the requester, nor provider have wires for
>>>> the
>>>> package.
>>>> // 2. The requester does not have a wire for the package.
>>>> // 3. The provider does not have a wire for the package.
>>>> // 4. Both the requester and provider have a wire for the
>>>> package.
>>>> // For case 1, if the requester does not have access to the
>>>> class at
>>>> // all, we assume it is using reflection and do not
>>>> filter. If
>>>> the
>>>> // requester does have access to the class, then we make
>>>> sure
>>>> it is
>>>> // the same class as the service. For case 2, we do not
>>>> filter
>>>> if the
>>>> // requester is the exporter of the package to which the
>>>> provider of
>>>> // the service is wired. Otherwise, as in case 1, if the
>>>> requester
>>>> // does not have access to the class at all, we do not
>>>> filter,
>>>> but if
>>>> // it does have access we check if it is the same class
>>>> accessible to
>>>> // the providing revision. For case 3, the provider will
>>>> not
>>>> have a wire
>>>> // if it is exporting the package, so we determine if the
>>>> requester
>>>> // is wired to it or somehow using the same class. For
>>>> case 4,
>>>> we
>>>> // simply compare the exporting revisions from the package
>>>> wiring to
>>>> // determine if we need to filter the service reference.
>>>>
>>>>
>>>> On 2/14/13 11:50 , Imóveis Nacionais wrote:
>>>>
>>>> Hi all, me again…
>>>>>
>>>>>
>>>>> Suppose you have the following OSGi bundles and the related exposed
>>>>> services:
>>>>>
>>>>> BundleService1 -> exports service 1 and interface for service 1
>>>>>
>>>>> BundleService2 -> exports service 2 and interface for service 2
>>>>>
>>>>>
>>>>>
>>>>> Now I want to write the Bundle3 which will use both Service1 and
>>>>> Service2
>>>>> (for now, just service1).
>>>>>
>>>>> So, Bundle3 (activator class) implements BundleActivator and
>>>>> ServiceListener.
>>>>>
>>>>> On start() I do: context.addServiceListener(****this);
>>>>>
>>>>>
>>>>> On the serviceChanged() method I simply have a print to console.
>>>>>
>>>>> This works with no problem.
>>>>>
>>>>> ------------------------------****----------------------------**--**
>>>>> ------------------------------****------------------
>>>>>
>>>>>
>>>>> Suppose now that you want to call service1 from serviceChanged method
>>>>> (just
>>>>> an example!):
>>>>>
>>>>> To call service1 I need to add dependence to pom.xml for
>>>>> BundleService1 in
>>>>> order to get reference and cast the reference to the service1
>>>>> interface.
>>>>>
>>>>> Then, on the activator class I need to put an import for the service1
>>>>> interface. Then I get the reference, evaluate the property, cast it to
>>>>> service1 and call the service1.
>>>>>
>>>>>
>>>>> Now, testing this stuff:
>>>>>
>>>>> I install Bundle3 and start it.
>>>>>
>>>>> I install BundleService1 and start it. Nothing happens on bundle3
>>>>> serviceChanged!!!
>>>>>
>>>>> Then I install BundleService2 and start it. The bundle3 serviceChanged
>>>>> is
>>>>> called!!!
>>>>>
>>>>>
>>>>> If I install and start any other bundles serviceChanged is always
>>>>> called,
>>>>> except for BundleService1!
>>>>>
>>>>> If I remove the import directive from Bundle3 (while the POM dependence
>>>>> remains) and comment the related code, Bundle3 serviceChanged is called
>>>>> for
>>>>> BundleService1!
>>>>>
>>>>>
>>>>>
>>>>> My conclusion is that, the ServiceListener only works for those bundles
>>>>> that have no “connection” (import) with Bundle3. Is this true?
>>>>>
>>>>> If this is true, how can I get the reference and cast to the service in
>>>>> order to call it without using imports?
>>>>>
>>>>>
>>>>>
>>>>> Note: In an attempt to solve the problem I did the following: in the
>>>>> serviceChanged I called another bundle3 class giving it the event in
>>>>> order
>>>>> to remove the import from activator class, and move it to the other
>>>>> class.
>>>>> But serviceChanged did not detects the Service1 too. It seems that if
>>>>> the
>>>>> (client) bundle project has an import for some service bundles those
>>>>> bundles are not “detected” in the serviceChanged method.
>>>>>
>>>>>
>>>>>
>>>>> Thank you
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>> ------------------------------****----------------------------**
>>>> --**---------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apac**he.org<http://apache.org>
>>>> <us...@felix.apache.org>
>>>> >
>>>>
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls
Re: ServiceListener influenced by import directive: could someone
confirm this?
Posted by Imóveis Nacionais <im...@gmail.com>.
Hi Richard, here it is...
Use the first zip for this first test case.
vigia-1.0.jar has just print instructions in the serviceChanged (source
code is also in attachment)
MyOSGi-1.0-SNAPSHOT.jar is a sample service bundle
MyBundleServer-1.0-SNAPSHOT.jar is another sample service bundle
Test this stuff like this :
g! install file:/C:/PROJS/OSGi/felix-framework-4.0.3/vigia-1.0.jar
Bundle ID: 86
g! start 86
Client bundle initializing on start method...
g!
then:
g! install file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyOSGi-1.0-SNAPSHOT.jar
Bundle ID: 88
g! start 88
Server bundle start method initializing
serviceChanged called...
Gestting description...
->This an service impl object
O serviþo foi registado! //Means service was registered, in english
g!
Then
g! install
file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyBundleServer-1.0-SNAPSHOT
.jar
Bundle ID: 89
g! start 89
Server bundle start method initializing
serviceChanged called...
Gestting description...
->GET_NUMBER_SERVICE
O serviþo foi registado!
g!
As you can see the 'global service' listener works well.
Now do the uninstallation of the 3 bundles:
g! uninstall 89
serviceChanged called...
Gestting description...
->GET_NUMBER_SERVICE
g! uninstall 88
Goodbye OSGi World
serviceChanged called...
Gestting description...
->This an service impl object
g! uninstall 86
g!
Now use the second zip file. In this zip file, vigia-1.0.jar has print
instructions in the serviceChanged but also an attempt to get a reference
for a service and a call to the service (source code is also in attachment
for vigia and for the project where interface is exported)
g! install file:/C:/PROJS/OSGi/felix-framework-4.0.3/vigia-1.0.jar
Bundle ID: 90
g! start 90
Client bundle initializing on start method...
Then
g! install file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyOSGi-1.0-SNAPSHOT.jar
Bundle ID: 91
g! start 91
Server bundle start method initializing
serviceChanged called...
->CALLED
Gestting description...
->This an service impl object
O serviþo foi registado!
g!
and then:
g! install
file:/C:/PROJS/OSGi/felix-framework-4.0.3/MyBundleServer-1.0-SNAPSHOT
.jar
Bundle ID: 94
-> serviceChanged NOT CALLED!
g! start 94
Server bundle start method initializing
O serviþo foi registado!
As you see the serviceChanged was not called this time. Even if you remove
all the code from serviceChanged and let only the prints and the import, it
is not called either. If you comment the code in serviceChanged (let only
the prints) and comment the import statement, then the serviceChanged is
called.
I am trying to understand this behavior... Thanks a lot
Alex
On Thu, Feb 14, 2013 at 11:44 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> If you want to create me a simple example of two bundles (one client and
> one server) where the client can't see the other, I'll take a look at it
> and try to explain what is going on...from your description, I'm still not
> sure what precisely is triggering the situation.
>
> -> richard
>
>
> On 2/14/13 6:40 PM, Imóveis Nacionais wrote:
>
>> My "AllServiceListener" takes place when serviceChanged( ) has just a
>> print
>> to console. In this situation all osgi services fire the serviceChanged()
>> method.
>>
>> The problem appears when I build a 'special listener' (for example for
>> BundleService1 as i said) in order to fill an handle to the service to be
>> called later. In this situation, to declare a variable of service1
>> interface to save the service object reference, I have to put the import
>> statement and the special listener does not detects service1 anymore, only
>> service 2,3, 4,etc...
>>
>> May be i am using ServiceListener in a worng way, but it is logic for me
>> to
>> get the pointer to the service when it is up...
>>
>> Thanks
>>
>> Alex
>>
>>
>>
>>
>> On Thu, Feb 14, 2013 at 6:55 PM, Richard S. Hall <heavy@ungoverned.org
>> >wrote:
>>
>> The OSGi framework attempts to deliver service events that are usable by
>>> your bundle (i.e., class compatible), so by having or not having imports
>>> and depending on the provider of your imports you may or may not see
>>> events
>>> if the framework thinks they might cause you class cast problems.
>>>
>>> If you want to test this out, you can implement *AllServiceListener* as a
>>>
>>> test to see if you get all events; this listener will get all service
>>> event
>>> irrespective of whether they might cause class cast exceptions.
>>>
>>> Generally, you only want to use an "all" listener if you are monitoring
>>> an
>>> entire system, but not really interacting with services (or are using
>>> reflection to do so). Normally, you only want the framework sending
>>> events
>>> to service you can access without a class cast exception using the normal
>>> ServiceListener.
>>>
>>> -> richard
>>>
>>> p.s. For completeness, here a description of what the Felix framework
>>> tries to do from ServiceRegistrationImpl.java:
>>>
>>> // There are four situations that may occur here:
>>> // 1. Neither the requester, nor provider have wires for
>>> the
>>> package.
>>> // 2. The requester does not have a wire for the package.
>>> // 3. The provider does not have a wire for the package.
>>> // 4. Both the requester and provider have a wire for the
>>> package.
>>> // For case 1, if the requester does not have access to the
>>> class at
>>> // all, we assume it is using reflection and do not filter.
>>> If
>>> the
>>> // requester does have access to the class, then we make
>>> sure
>>> it is
>>> // the same class as the service. For case 2, we do not
>>> filter
>>> if the
>>> // requester is the exporter of the package to which the
>>> provider of
>>> // the service is wired. Otherwise, as in case 1, if the
>>> requester
>>> // does not have access to the class at all, we do not
>>> filter,
>>> but if
>>> // it does have access we check if it is the same class
>>> accessible to
>>> // the providing revision. For case 3, the provider will not
>>> have a wire
>>> // if it is exporting the package, so we determine if the
>>> requester
>>> // is wired to it or somehow using the same class. For case
>>> 4,
>>> we
>>> // simply compare the exporting revisions from the package
>>> wiring to
>>> // determine if we need to filter the service reference.
>>>
>>>
>>> On 2/14/13 11:50 , Imóveis Nacionais wrote:
>>>
>>> Hi all, me again…
>>>>
>>>>
>>>> Suppose you have the following OSGi bundles and the related exposed
>>>> services:
>>>>
>>>> BundleService1 -> exports service 1 and interface for service 1
>>>>
>>>> BundleService2 -> exports service 2 and interface for service 2
>>>>
>>>>
>>>>
>>>> Now I want to write the Bundle3 which will use both Service1 and
>>>> Service2
>>>> (for now, just service1).
>>>>
>>>> So, Bundle3 (activator class) implements BundleActivator and
>>>> ServiceListener.
>>>>
>>>> On start() I do: context.addServiceListener(****this);
>>>>
>>>>
>>>> On the serviceChanged() method I simply have a print to console.
>>>>
>>>> This works with no problem.
>>>>
>>>> ------------------------------****----------------------------**--**
>>>> ------------------------------****------------------
>>>>
>>>>
>>>> Suppose now that you want to call service1 from serviceChanged method
>>>> (just
>>>> an example!):
>>>>
>>>> To call service1 I need to add dependence to pom.xml for BundleService1
>>>> in
>>>> order to get reference and cast the reference to the service1 interface.
>>>>
>>>> Then, on the activator class I need to put an import for the service1
>>>> interface. Then I get the reference, evaluate the property, cast it to
>>>> service1 and call the service1.
>>>>
>>>>
>>>> Now, testing this stuff:
>>>>
>>>> I install Bundle3 and start it.
>>>>
>>>> I install BundleService1 and start it. Nothing happens on bundle3
>>>> serviceChanged!!!
>>>>
>>>> Then I install BundleService2 and start it. The bundle3 serviceChanged
>>>> is
>>>> called!!!
>>>>
>>>>
>>>> If I install and start any other bundles serviceChanged is always
>>>> called,
>>>> except for BundleService1!
>>>>
>>>> If I remove the import directive from Bundle3 (while the POM dependence
>>>> remains) and comment the related code, Bundle3 serviceChanged is called
>>>> for
>>>> BundleService1!
>>>>
>>>>
>>>>
>>>> My conclusion is that, the ServiceListener only works for those bundles
>>>> that have no “connection” (import) with Bundle3. Is this true?
>>>>
>>>> If this is true, how can I get the reference and cast to the service in
>>>> order to call it without using imports?
>>>>
>>>>
>>>>
>>>> Note: In an attempt to solve the problem I did the following: in the
>>>> serviceChanged I called another bundle3 class giving it the event in
>>>> order
>>>> to remove the import from activator class, and move it to the other
>>>> class.
>>>> But serviceChanged did not detects the Service1 too. It seems that if
>>>> the
>>>> (client) bundle project has an import for some service bundles those
>>>> bundles are not “detected” in the serviceChanged method.
>>>>
>>>>
>>>>
>>>> Thank you
>>>>
>>>> Alex
>>>>
>>>>
>>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.**apac**he.org<http://apache.org>
>>> <us...@felix.apache.org>
>>> >
>>>
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: ServiceListener influenced by import directive: could someone
confirm this?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
If you want to create me a simple example of two bundles (one client and
one server) where the client can't see the other, I'll take a look at it
and try to explain what is going on...from your description, I'm still
not sure what precisely is triggering the situation.
-> richard
On 2/14/13 6:40 PM, Imóveis Nacionais wrote:
> My "AllServiceListener" takes place when serviceChanged( ) has just a print
> to console. In this situation all osgi services fire the serviceChanged()
> method.
>
> The problem appears when I build a 'special listener' (for example for
> BundleService1 as i said) in order to fill an handle to the service to be
> called later. In this situation, to declare a variable of service1
> interface to save the service object reference, I have to put the import
> statement and the special listener does not detects service1 anymore, only
> service 2,3, 4,etc...
>
> May be i am using ServiceListener in a worng way, but it is logic for me to
> get the pointer to the service when it is up...
>
> Thanks
>
> Alex
>
>
>
>
> On Thu, Feb 14, 2013 at 6:55 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> The OSGi framework attempts to deliver service events that are usable by
>> your bundle (i.e., class compatible), so by having or not having imports
>> and depending on the provider of your imports you may or may not see events
>> if the framework thinks they might cause you class cast problems.
>>
>> If you want to test this out, you can implement *AllServiceListener* as a
>> test to see if you get all events; this listener will get all service event
>> irrespective of whether they might cause class cast exceptions.
>>
>> Generally, you only want to use an "all" listener if you are monitoring an
>> entire system, but not really interacting with services (or are using
>> reflection to do so). Normally, you only want the framework sending events
>> to service you can access without a class cast exception using the normal
>> ServiceListener.
>>
>> -> richard
>>
>> p.s. For completeness, here a description of what the Felix framework
>> tries to do from ServiceRegistrationImpl.java:
>>
>> // There are four situations that may occur here:
>> // 1. Neither the requester, nor provider have wires for the
>> package.
>> // 2. The requester does not have a wire for the package.
>> // 3. The provider does not have a wire for the package.
>> // 4. Both the requester and provider have a wire for the
>> package.
>> // For case 1, if the requester does not have access to the
>> class at
>> // all, we assume it is using reflection and do not filter. If
>> the
>> // requester does have access to the class, then we make sure
>> it is
>> // the same class as the service. For case 2, we do not filter
>> if the
>> // requester is the exporter of the package to which the
>> provider of
>> // the service is wired. Otherwise, as in case 1, if the
>> requester
>> // does not have access to the class at all, we do not filter,
>> but if
>> // it does have access we check if it is the same class
>> accessible to
>> // the providing revision. For case 3, the provider will not
>> have a wire
>> // if it is exporting the package, so we determine if the
>> requester
>> // is wired to it or somehow using the same class. For case 4,
>> we
>> // simply compare the exporting revisions from the package
>> wiring to
>> // determine if we need to filter the service reference.
>>
>>
>> On 2/14/13 11:50 , Imóveis Nacionais wrote:
>>
>>> Hi all, me again…
>>>
>>>
>>> Suppose you have the following OSGi bundles and the related exposed
>>> services:
>>>
>>> BundleService1 -> exports service 1 and interface for service 1
>>>
>>> BundleService2 -> exports service 2 and interface for service 2
>>>
>>>
>>>
>>> Now I want to write the Bundle3 which will use both Service1 and Service2
>>> (for now, just service1).
>>>
>>> So, Bundle3 (activator class) implements BundleActivator and
>>> ServiceListener.
>>>
>>> On start() I do: context.addServiceListener(**this);
>>>
>>> On the serviceChanged() method I simply have a print to console.
>>>
>>> This works with no problem.
>>>
>>> ------------------------------**------------------------------**
>>> ------------------------------**------------------
>>>
>>> Suppose now that you want to call service1 from serviceChanged method
>>> (just
>>> an example!):
>>>
>>> To call service1 I need to add dependence to pom.xml for BundleService1 in
>>> order to get reference and cast the reference to the service1 interface.
>>>
>>> Then, on the activator class I need to put an import for the service1
>>> interface. Then I get the reference, evaluate the property, cast it to
>>> service1 and call the service1.
>>>
>>>
>>> Now, testing this stuff:
>>>
>>> I install Bundle3 and start it.
>>>
>>> I install BundleService1 and start it. Nothing happens on bundle3
>>> serviceChanged!!!
>>>
>>> Then I install BundleService2 and start it. The bundle3 serviceChanged is
>>> called!!!
>>>
>>>
>>> If I install and start any other bundles serviceChanged is always called,
>>> except for BundleService1!
>>>
>>> If I remove the import directive from Bundle3 (while the POM dependence
>>> remains) and comment the related code, Bundle3 serviceChanged is called
>>> for
>>> BundleService1!
>>>
>>>
>>>
>>> My conclusion is that, the ServiceListener only works for those bundles
>>> that have no “connection” (import) with Bundle3. Is this true?
>>>
>>> If this is true, how can I get the reference and cast to the service in
>>> order to call it without using imports?
>>>
>>>
>>>
>>> Note: In an attempt to solve the problem I did the following: in the
>>> serviceChanged I called another bundle3 class giving it the event in order
>>> to remove the import from activator class, and move it to the other class.
>>> But serviceChanged did not detects the Service1 too. It seems that if the
>>> (client) bundle project has an import for some service bundles those
>>> bundles are not “detected” in the serviceChanged method.
>>>
>>>
>>>
>>> Thank you
>>>
>>> Alex
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ServiceListener influenced by import directive: could someone confirm this?
Posted by David Jencks <da...@yahoo.com>.
Along with the other comments…. Another way to investigate this is to enhance your AllServiceListener to get the service from the service reference in the service event, get the class, the class loader, and cast it to BundleReference, and print the bundle. You can also check which bundle the import is wired to in pretty much the same way. If they are different…. that's the explanation.
hope this helps
david jencks
On Feb 14, 2013, at 3:40 PM, Imóveis Nacionais <im...@gmail.com> wrote:
> My "AllServiceListener" takes place when serviceChanged( ) has just a print
> to console. In this situation all osgi services fire the serviceChanged()
> method.
>
> The problem appears when I build a 'special listener' (for example for
> BundleService1 as i said) in order to fill an handle to the service to be
> called later. In this situation, to declare a variable of service1
> interface to save the service object reference, I have to put the import
> statement and the special listener does not detects service1 anymore, only
> service 2,3, 4,etc...
>
> May be i am using ServiceListener in a worng way, but it is logic for me to
> get the pointer to the service when it is up...
>
> Thanks
>
> Alex
>
>
>
>
> On Thu, Feb 14, 2013 at 6:55 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> The OSGi framework attempts to deliver service events that are usable by
>> your bundle (i.e., class compatible), so by having or not having imports
>> and depending on the provider of your imports you may or may not see events
>> if the framework thinks they might cause you class cast problems.
>>
>> If you want to test this out, you can implement *AllServiceListener* as a
>> test to see if you get all events; this listener will get all service event
>> irrespective of whether they might cause class cast exceptions.
>>
>> Generally, you only want to use an "all" listener if you are monitoring an
>> entire system, but not really interacting with services (or are using
>> reflection to do so). Normally, you only want the framework sending events
>> to service you can access without a class cast exception using the normal
>> ServiceListener.
>>
>> -> richard
>>
>> p.s. For completeness, here a description of what the Felix framework
>> tries to do from ServiceRegistrationImpl.java:
>>
>> // There are four situations that may occur here:
>> // 1. Neither the requester, nor provider have wires for the
>> package.
>> // 2. The requester does not have a wire for the package.
>> // 3. The provider does not have a wire for the package.
>> // 4. Both the requester and provider have a wire for the
>> package.
>> // For case 1, if the requester does not have access to the
>> class at
>> // all, we assume it is using reflection and do not filter. If
>> the
>> // requester does have access to the class, then we make sure
>> it is
>> // the same class as the service. For case 2, we do not filter
>> if the
>> // requester is the exporter of the package to which the
>> provider of
>> // the service is wired. Otherwise, as in case 1, if the
>> requester
>> // does not have access to the class at all, we do not filter,
>> but if
>> // it does have access we check if it is the same class
>> accessible to
>> // the providing revision. For case 3, the provider will not
>> have a wire
>> // if it is exporting the package, so we determine if the
>> requester
>> // is wired to it or somehow using the same class. For case 4,
>> we
>> // simply compare the exporting revisions from the package
>> wiring to
>> // determine if we need to filter the service reference.
>>
>>
>> On 2/14/13 11:50 , Imóveis Nacionais wrote:
>>
>>> Hi all, me again…
>>>
>>>
>>> Suppose you have the following OSGi bundles and the related exposed
>>> services:
>>>
>>> BundleService1 -> exports service 1 and interface for service 1
>>>
>>> BundleService2 -> exports service 2 and interface for service 2
>>>
>>>
>>>
>>> Now I want to write the Bundle3 which will use both Service1 and Service2
>>> (for now, just service1).
>>>
>>> So, Bundle3 (activator class) implements BundleActivator and
>>> ServiceListener.
>>>
>>> On start() I do: context.addServiceListener(**this);
>>>
>>> On the serviceChanged() method I simply have a print to console.
>>>
>>> This works with no problem.
>>>
>>> ------------------------------**------------------------------**
>>> ------------------------------**------------------
>>>
>>> Suppose now that you want to call service1 from serviceChanged method
>>> (just
>>> an example!):
>>>
>>> To call service1 I need to add dependence to pom.xml for BundleService1 in
>>> order to get reference and cast the reference to the service1 interface.
>>>
>>> Then, on the activator class I need to put an import for the service1
>>> interface. Then I get the reference, evaluate the property, cast it to
>>> service1 and call the service1.
>>>
>>>
>>> Now, testing this stuff:
>>>
>>> I install Bundle3 and start it.
>>>
>>> I install BundleService1 and start it. Nothing happens on bundle3
>>> serviceChanged!!!
>>>
>>> Then I install BundleService2 and start it. The bundle3 serviceChanged is
>>> called!!!
>>>
>>>
>>> If I install and start any other bundles serviceChanged is always called,
>>> except for BundleService1!
>>>
>>> If I remove the import directive from Bundle3 (while the POM dependence
>>> remains) and comment the related code, Bundle3 serviceChanged is called
>>> for
>>> BundleService1!
>>>
>>>
>>>
>>> My conclusion is that, the ServiceListener only works for those bundles
>>> that have no “connection” (import) with Bundle3. Is this true?
>>>
>>> If this is true, how can I get the reference and cast to the service in
>>> order to call it without using imports?
>>>
>>>
>>>
>>> Note: In an attempt to solve the problem I did the following: in the
>>> serviceChanged I called another bundle3 class giving it the event in order
>>> to remove the import from activator class, and move it to the other class.
>>> But serviceChanged did not detects the Service1 too. It seems that if the
>>> (client) bundle project has an import for some service bundles those
>>> bundles are not “detected” in the serviceChanged method.
>>>
>>>
>>>
>>> Thank you
>>>
>>> Alex
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ServiceListener influenced by import directive: could someone
confirm this?
Posted by Neil Bartlett <nj...@gmail.com>.
It's worth checking (via the "inspect req osgi.wiring.package <bundle>"
command) whether the import in Bundle 3 is actually wired to the exported
package in Bundle 1.
For example if the bundles have been incorrectly packaged then you might
have a second copy of the interface somewhere, and therefore the
compatibility rules mentioned by Richard would be relevant.
Neil
On Thu, Feb 14, 2013 at 11:40 PM, Imóveis Nacionais <
imoveisnacionais@gmail.com> wrote:
> My "AllServiceListener" takes place when serviceChanged( ) has just a print
> to console. In this situation all osgi services fire the serviceChanged()
> method.
>
> The problem appears when I build a 'special listener' (for example for
> BundleService1 as i said) in order to fill an handle to the service to be
> called later. In this situation, to declare a variable of service1
> interface to save the service object reference, I have to put the import
> statement and the special listener does not detects service1 anymore, only
> service 2,3, 4,etc...
>
> May be i am using ServiceListener in a worng way, but it is logic for me to
> get the pointer to the service when it is up...
>
> Thanks
>
> Alex
>
>
>
>
> On Thu, Feb 14, 2013 at 6:55 PM, Richard S. Hall <heavy@ungoverned.org
> >wrote:
>
> > The OSGi framework attempts to deliver service events that are usable by
> > your bundle (i.e., class compatible), so by having or not having imports
> > and depending on the provider of your imports you may or may not see
> events
> > if the framework thinks they might cause you class cast problems.
> >
> > If you want to test this out, you can implement *AllServiceListener* as a
> > test to see if you get all events; this listener will get all service
> event
> > irrespective of whether they might cause class cast exceptions.
> >
> > Generally, you only want to use an "all" listener if you are monitoring
> an
> > entire system, but not really interacting with services (or are using
> > reflection to do so). Normally, you only want the framework sending
> events
> > to service you can access without a class cast exception using the normal
> > ServiceListener.
> >
> > -> richard
> >
> > p.s. For completeness, here a description of what the Felix framework
> > tries to do from ServiceRegistrationImpl.java:
> >
> > // There are four situations that may occur here:
> > // 1. Neither the requester, nor provider have wires for
> the
> > package.
> > // 2. The requester does not have a wire for the package.
> > // 3. The provider does not have a wire for the package.
> > // 4. Both the requester and provider have a wire for the
> > package.
> > // For case 1, if the requester does not have access to the
> > class at
> > // all, we assume it is using reflection and do not filter.
> If
> > the
> > // requester does have access to the class, then we make sure
> > it is
> > // the same class as the service. For case 2, we do not
> filter
> > if the
> > // requester is the exporter of the package to which the
> > provider of
> > // the service is wired. Otherwise, as in case 1, if the
> > requester
> > // does not have access to the class at all, we do not
> filter,
> > but if
> > // it does have access we check if it is the same class
> > accessible to
> > // the providing revision. For case 3, the provider will not
> > have a wire
> > // if it is exporting the package, so we determine if the
> > requester
> > // is wired to it or somehow using the same class. For case
> 4,
> > we
> > // simply compare the exporting revisions from the package
> > wiring to
> > // determine if we need to filter the service reference.
> >
> >
> > On 2/14/13 11:50 , Imóveis Nacionais wrote:
> >
> >> Hi all, me again…
> >>
> >>
> >> Suppose you have the following OSGi bundles and the related exposed
> >> services:
> >>
> >> BundleService1 -> exports service 1 and interface for service 1
> >>
> >> BundleService2 -> exports service 2 and interface for service 2
> >>
> >>
> >>
> >> Now I want to write the Bundle3 which will use both Service1 and
> Service2
> >> (for now, just service1).
> >>
> >> So, Bundle3 (activator class) implements BundleActivator and
> >> ServiceListener.
> >>
> >> On start() I do: context.addServiceListener(**this);
> >>
> >> On the serviceChanged() method I simply have a print to console.
> >>
> >> This works with no problem.
> >>
> >> ------------------------------**------------------------------**
> >> ------------------------------**------------------
> >>
> >> Suppose now that you want to call service1 from serviceChanged method
> >> (just
> >> an example!):
> >>
> >> To call service1 I need to add dependence to pom.xml for BundleService1
> in
> >> order to get reference and cast the reference to the service1 interface.
> >>
> >> Then, on the activator class I need to put an import for the service1
> >> interface. Then I get the reference, evaluate the property, cast it to
> >> service1 and call the service1.
> >>
> >>
> >> Now, testing this stuff:
> >>
> >> I install Bundle3 and start it.
> >>
> >> I install BundleService1 and start it. Nothing happens on bundle3
> >> serviceChanged!!!
> >>
> >> Then I install BundleService2 and start it. The bundle3 serviceChanged
> is
> >> called!!!
> >>
> >>
> >> If I install and start any other bundles serviceChanged is always
> called,
> >> except for BundleService1!
> >>
> >> If I remove the import directive from Bundle3 (while the POM dependence
> >> remains) and comment the related code, Bundle3 serviceChanged is called
> >> for
> >> BundleService1!
> >>
> >>
> >>
> >> My conclusion is that, the ServiceListener only works for those bundles
> >> that have no “connection” (import) with Bundle3. Is this true?
> >>
> >> If this is true, how can I get the reference and cast to the service in
> >> order to call it without using imports?
> >>
> >>
> >>
> >> Note: In an attempt to solve the problem I did the following: in the
> >> serviceChanged I called another bundle3 class giving it the event in
> order
> >> to remove the import from activator class, and move it to the other
> class.
> >> But serviceChanged did not detects the Service1 too. It seems that if
> the
> >> (client) bundle project has an import for some service bundles those
> >> bundles are not “detected” in the serviceChanged method.
> >>
> >>
> >>
> >> Thank you
> >>
> >> Alex
> >>
> >>
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<
> users-unsubscribe@felix.apache.org>
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
Re: ServiceListener influenced by import directive: could someone
confirm this?
Posted by Imóveis Nacionais <im...@gmail.com>.
My "AllServiceListener" takes place when serviceChanged( ) has just a print
to console. In this situation all osgi services fire the serviceChanged()
method.
The problem appears when I build a 'special listener' (for example for
BundleService1 as i said) in order to fill an handle to the service to be
called later. In this situation, to declare a variable of service1
interface to save the service object reference, I have to put the import
statement and the special listener does not detects service1 anymore, only
service 2,3, 4,etc...
May be i am using ServiceListener in a worng way, but it is logic for me to
get the pointer to the service when it is up...
Thanks
Alex
On Thu, Feb 14, 2013 at 6:55 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> The OSGi framework attempts to deliver service events that are usable by
> your bundle (i.e., class compatible), so by having or not having imports
> and depending on the provider of your imports you may or may not see events
> if the framework thinks they might cause you class cast problems.
>
> If you want to test this out, you can implement *AllServiceListener* as a
> test to see if you get all events; this listener will get all service event
> irrespective of whether they might cause class cast exceptions.
>
> Generally, you only want to use an "all" listener if you are monitoring an
> entire system, but not really interacting with services (or are using
> reflection to do so). Normally, you only want the framework sending events
> to service you can access without a class cast exception using the normal
> ServiceListener.
>
> -> richard
>
> p.s. For completeness, here a description of what the Felix framework
> tries to do from ServiceRegistrationImpl.java:
>
> // There are four situations that may occur here:
> // 1. Neither the requester, nor provider have wires for the
> package.
> // 2. The requester does not have a wire for the package.
> // 3. The provider does not have a wire for the package.
> // 4. Both the requester and provider have a wire for the
> package.
> // For case 1, if the requester does not have access to the
> class at
> // all, we assume it is using reflection and do not filter. If
> the
> // requester does have access to the class, then we make sure
> it is
> // the same class as the service. For case 2, we do not filter
> if the
> // requester is the exporter of the package to which the
> provider of
> // the service is wired. Otherwise, as in case 1, if the
> requester
> // does not have access to the class at all, we do not filter,
> but if
> // it does have access we check if it is the same class
> accessible to
> // the providing revision. For case 3, the provider will not
> have a wire
> // if it is exporting the package, so we determine if the
> requester
> // is wired to it or somehow using the same class. For case 4,
> we
> // simply compare the exporting revisions from the package
> wiring to
> // determine if we need to filter the service reference.
>
>
> On 2/14/13 11:50 , Imóveis Nacionais wrote:
>
>> Hi all, me again…
>>
>>
>> Suppose you have the following OSGi bundles and the related exposed
>> services:
>>
>> BundleService1 -> exports service 1 and interface for service 1
>>
>> BundleService2 -> exports service 2 and interface for service 2
>>
>>
>>
>> Now I want to write the Bundle3 which will use both Service1 and Service2
>> (for now, just service1).
>>
>> So, Bundle3 (activator class) implements BundleActivator and
>> ServiceListener.
>>
>> On start() I do: context.addServiceListener(**this);
>>
>> On the serviceChanged() method I simply have a print to console.
>>
>> This works with no problem.
>>
>> ------------------------------**------------------------------**
>> ------------------------------**------------------
>>
>> Suppose now that you want to call service1 from serviceChanged method
>> (just
>> an example!):
>>
>> To call service1 I need to add dependence to pom.xml for BundleService1 in
>> order to get reference and cast the reference to the service1 interface.
>>
>> Then, on the activator class I need to put an import for the service1
>> interface. Then I get the reference, evaluate the property, cast it to
>> service1 and call the service1.
>>
>>
>> Now, testing this stuff:
>>
>> I install Bundle3 and start it.
>>
>> I install BundleService1 and start it. Nothing happens on bundle3
>> serviceChanged!!!
>>
>> Then I install BundleService2 and start it. The bundle3 serviceChanged is
>> called!!!
>>
>>
>> If I install and start any other bundles serviceChanged is always called,
>> except for BundleService1!
>>
>> If I remove the import directive from Bundle3 (while the POM dependence
>> remains) and comment the related code, Bundle3 serviceChanged is called
>> for
>> BundleService1!
>>
>>
>>
>> My conclusion is that, the ServiceListener only works for those bundles
>> that have no “connection” (import) with Bundle3. Is this true?
>>
>> If this is true, how can I get the reference and cast to the service in
>> order to call it without using imports?
>>
>>
>>
>> Note: In an attempt to solve the problem I did the following: in the
>> serviceChanged I called another bundle3 class giving it the event in order
>> to remove the import from activator class, and move it to the other class.
>> But serviceChanged did not detects the Service1 too. It seems that if the
>> (client) bundle project has an import for some service bundles those
>> bundles are not “detected” in the serviceChanged method.
>>
>>
>>
>> Thank you
>>
>> Alex
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: ServiceListener influenced by import directive: could someone
confirm this?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
The OSGi framework attempts to deliver service events that are usable by
your bundle (i.e., class compatible), so by having or not having imports
and depending on the provider of your imports you may or may not see
events if the framework thinks they might cause you class cast problems.
If you want to test this out, you can implement AllServiceListener as a
test to see if you get all events; this listener will get all service
event irrespective of whether they might cause class cast exceptions.
Generally, you only want to use an "all" listener if you are monitoring
an entire system, but not really interacting with services (or are using
reflection to do so). Normally, you only want the framework sending
events to service you can access without a class cast exception using
the normal ServiceListener.
-> richard
p.s. For completeness, here a description of what the Felix framework
tries to do from ServiceRegistrationImpl.java:
// There are four situations that may occur here:
// 1. Neither the requester, nor provider have wires for
the package.
// 2. The requester does not have a wire for the package.
// 3. The provider does not have a wire for the package.
// 4. Both the requester and provider have a wire for the
package.
// For case 1, if the requester does not have access to the
class at
// all, we assume it is using reflection and do not filter.
If the
// requester does have access to the class, then we make
sure it is
// the same class as the service. For case 2, we do not
filter if the
// requester is the exporter of the package to which the
provider of
// the service is wired. Otherwise, as in case 1, if the
requester
// does not have access to the class at all, we do not
filter, but if
// it does have access we check if it is the same class
accessible to
// the providing revision. For case 3, the provider will
not have a wire
// if it is exporting the package, so we determine if the
requester
// is wired to it or somehow using the same class. For case
4, we
// simply compare the exporting revisions from the package
wiring to
// determine if we need to filter the service reference.
On 2/14/13 11:50 , Imóveis Nacionais wrote:
> Hi all, me again…
>
>
> Suppose you have the following OSGi bundles and the related exposed
> services:
>
> BundleService1 -> exports service 1 and interface for service 1
>
> BundleService2 -> exports service 2 and interface for service 2
>
>
>
> Now I want to write the Bundle3 which will use both Service1 and Service2
> (for now, just service1).
>
> So, Bundle3 (activator class) implements BundleActivator and
> ServiceListener.
>
> On start() I do: context.addServiceListener(this);
>
> On the serviceChanged() method I simply have a print to console.
>
> This works with no problem.
>
> ------------------------------------------------------------------------------------------------------------
>
> Suppose now that you want to call service1 from serviceChanged method (just
> an example!):
>
> To call service1 I need to add dependence to pom.xml for BundleService1 in
> order to get reference and cast the reference to the service1 interface.
>
> Then, on the activator class I need to put an import for the service1
> interface. Then I get the reference, evaluate the property, cast it to
> service1 and call the service1.
>
>
> Now, testing this stuff:
>
> I install Bundle3 and start it.
>
> I install BundleService1 and start it. Nothing happens on bundle3
> serviceChanged!!!
>
> Then I install BundleService2 and start it. The bundle3 serviceChanged is
> called!!!
>
>
> If I install and start any other bundles serviceChanged is always called,
> except for BundleService1!
>
> If I remove the import directive from Bundle3 (while the POM dependence
> remains) and comment the related code, Bundle3 serviceChanged is called for
> BundleService1!
>
>
>
> My conclusion is that, the ServiceListener only works for those bundles
> that have no “connection” (import) with Bundle3. Is this true?
>
> If this is true, how can I get the reference and cast to the service in
> order to call it without using imports?
>
>
>
> Note: In an attempt to solve the problem I did the following: in the
> serviceChanged I called another bundle3 class giving it the event in order
> to remove the import from activator class, and move it to the other class.
> But serviceChanged did not detects the Service1 too. It seems that if the
> (client) bundle project has an import for some service bundles those
> bundles are not “detected” in the serviceChanged method.
>
>
>
> Thank you
>
> Alex
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org