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 <[email protected]> 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 <[email protected]>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<[email protected]> >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
