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 <[email protected]> wrote:

try to call:

refresh

after each uninstall

regards,

Karl


On Fri, Feb 15, 2013 at 1:36 AM, Imóveis Nacionais <
[email protected]> 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 <[email protected]
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 <[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.**apac**he.org<
http://apache.org>
<users-unsubscribe@**felix.apache.org<
[email protected]>
For additional commands, e-mail: [email protected]




------------------------------**------------------------------**---------
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]



--
Karl Pauls
[email protected]
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to