Re: [equinox-dev] is this a service tracker bug?
I see - It's in an IllegalState until you refresh On 25/01/2008, Mark [EMAIL PROTECTED] wrote: Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi stop 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start( BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start( FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute (FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand (FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console( FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run( FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage (AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start( SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass (EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass (ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass( DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass( BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass( SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal( BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass( DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run( BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage (AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start( SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass (EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass (ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass( DefaultClassLoader.java:189) at
Re: [equinox-dev] is this a service tracker bug?
Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi stop 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start( BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start( FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute (FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand( FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console( FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run( FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage (AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java :400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass (EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass( ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass( DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass( BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass( SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal( BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass( DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run( BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage (AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java :400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass (EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass( ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass( DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass( BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass( SingleSourcePackage.java:37) at
Re: [equinox-dev] is this a service tracker bug?
Mark, Since your service interface (IA.java) is contained within bundleA, bundleB requires a package import from bundleA. The effect that you're seeing is that the old version of bundleA remains in the system and is still used by bundleB after you call update. Therefore you now have two instances of bundleA in the system: the old one, still used by bundleB, and the new refreshed one. Since you called 'refresh', the old bundleA was stopped, and so were any registered services (which is why you see 'removedService'). The new bundleA was also started, and a new IA service was registered. However, since bundleB is still using the package import from the old bundleA, it does not get notified of the new bundleA's service (refer to ServiceListener vs. AllServiceListener). Calling 'refresh' instructs the framework to perform the steps outlined at http://www2.osgi.org/javadoc/r4/org/osgi/service/packageadmin/PackageAdmin.html#refreshPackages(org.osgi.framework.Bundle[]). This in turn stops bundleB, gets rid of the old bundleA and links bundleB to the new bundleA's package source. When bundleB is restarted and linked to the new bundleA, it can once again see the IA service. Sorry if that was a bit confusing.. maybe someone else can clarify a bit more. -Jeremy On Jan 25, 2008 11:33 AM, Mark [EMAIL PROTECTED] wrote: This is driving me mad. I have two bundles A and B. B track the service offered by A. However if I call update on A then I get a remove Service notification but no add Service notification - that is until I issue a refresh command ? is this a bug? I have written the same simple code 10 time .. see the results. I have attached the two bundles and the two eclipse plugin projects (as one zip) - just in case a Eclipse/OSGi guru like yourself can figure it out? C:\egjava -jar equinox.osgi.jar -console osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 osgi install file:bundleA_1.0.0.jar Bundle id is 1 osgi install file:bundleB_1.0.0.jar Bundle id is 2 osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 1 INSTALLED bundleA_1.0.0 2 INSTALLED bundleB_1.0.0 osgi start 1 osgi start 2 addingService osgi stop 1 removedService osgi start 1 addingService osgi update 1 removedService - no add ! osgi stop 2 osgi start 2 osgi refresh - Only get add after refresh osgi addingService osgi On 25/01/2008, Neil Bartlett [EMAIL PROTECTED] wrote: Hi Mark, Many thanks for your kind words! Regarding the service tracker problem... that's not the behaviour I would expect to see, and I've just put together a small test case which prints a message in the addingService, removedService and modifiedService methods of the ServiceTracker. When I update the bundle that registered the service, I see the following: osgi update 5 Removed service Added service osgi Which seems to be the way it should work. I suggest posting a message to the equinox-dev mailing list ( https://dev.eclipse.org/mailman/listinfo/equinox-dev) explaining the problem in detail and including a minimal code sample that reproduces the problem. Regards, Neil On 25 Jan 2008, at 13:42, Mark wrote: Neil, First off I have to thank you in a big way, because it was you articles that got me up and running on OSGI. I am also glad that you are putting together a book... because I was thinking about it myself...in practice or in action!, would you like some help? ..Anyway the reason for this mail... I was looking at the Listeners Considered Harmful: The Whiteboard Pattern white paper, and I put together a very simple two bundle example (on Equinox), Bundle A (offers a service) Bundle B (consumes service A, using a Service Tracker) So far so good, and not exactly rocket science. However this morning I discovered that if you update A - then you must refresh A in order for B to receive the added service event. This came as a surprise, go I Googled a while, and came up short. So I was wondering if you had some words of widom for me on this ? Kind Regards Mark ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] is this a service tracker bug?
Mark, I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=216648 for you. I tried to CC you to the bug but I noticed you did not seem to have a bugzilla e-mail, unless you use a different e-mail for bugzilla than the one you use to post to equinox-dev. Tom From: Mark [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/25/2008 02:43 PM Subject:Re: [equinox-dev] is this a service tracker bug? :( I'll file a report - one other solution pointed out was to seperate interface (api) from the impl and the client. So I guess I should create A, B, and C (A)pi, Impl-(B)undle, and (C)lient Regards osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi update 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved
Re: [equinox-dev] is this a service tracker bug?
But you should not have to refresh. That is the whole point of importing the package which is exported. So that A' can import it from A which is where B imports it from. I think the IllegalStateException is is a bug in Equinox. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mark [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008-01-25 13:06 Subject: Re: [equinox-dev] is this a service tracker bug? I see - It's in an IllegalState until you refresh On 25/01/2008, Mark [EMAIL PROTECTED] wrote: Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi stop 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start
Re: [equinox-dev] is this a service tracker bug?
That seems to be a bug in Equinox. You may wish to file a bug report. For giggles, try update 1 without stopping it first. The update operation will automatically stop and restart the updated bundle. Note: in order for import and exporting the package to work here, the exported package in A' must be backwards compatible with the exported package in A. This is because the remaining code in A' will be implementing/using the interface from A. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mark [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008-01-25 12:59 Subject: Re: [equinox-dev] is this a service tracker bug? Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi stop 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376
Re: [equinox-dev] is this a service tracker bug?
Thanks. So that's expected behaviour - and all makes sense. Regards Mark On 25/01/2008, Jeremy Volkman [EMAIL PROTECTED] wrote: Mark, Since your service interface (IA.java) is contained within bundleA, bundleB requires a package import from bundleA. The effect that you're seeing is that the old version of bundleA remains in the system and is still used by bundleB after you call update. Therefore you now have two instances of bundleA in the system: the old one, still used by bundleB, and the new refreshed one. Since you called 'refresh', the old bundleA was stopped, and so were any registered services (which is why you see 'removedService'). The new bundleA was also started, and a new IA service was registered. However, since bundleB is still using the package import from the old bundleA, it does not get notified of the new bundleA's service (refer to ServiceListener vs. AllServiceListener). Calling 'refresh' instructs the framework to perform the steps outlined at http://www2.osgi.org/javadoc/r4/org/osgi/service/packageadmin/PackageAdmin.html#refreshPackages(org.osgi.framework.Bundle[]) . This in turn stops bundleB, gets rid of the old bundleA and links bundleB to the new bundleA's package source. When bundleB is restarted and linked to the new bundleA, it can once again see the IA service. Sorry if that was a bit confusing.. maybe someone else can clarify a bit more. -Jeremy On Jan 25, 2008 11:33 AM, Mark [EMAIL PROTECTED] wrote: This is driving me mad. I have two bundles A and B. B track the service offered by A. However if I call update on A then I get a remove Service notification but no add Service notification - that is until I issue a refresh command ? is this a bug? I have written the same simple code 10 time .. see the results. I have attached the two bundles and the two eclipse plugin projects (as one zip) - just in case a Eclipse/OSGi guru like yourself can figure it out? C:\egjava -jar equinox.osgi.jar -console osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 osgi install file:bundleA_1.0.0.jar Bundle id is 1 osgi install file:bundleB_1.0.0.jar Bundle id is 2 osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 1 INSTALLED bundleA_1.0.0 2 INSTALLED bundleB_1.0.0 osgi start 1 osgi start 2 addingService osgi stop 1 removedService osgi start 1 addingService osgi update 1 removedService - no add ! osgi stop 2 osgi start 2 osgi refresh - Only get add after refresh osgi addingService osgi On 25/01/2008, Neil Bartlett [EMAIL PROTECTED] wrote: Hi Mark, Many thanks for your kind words! Regarding the service tracker problem... that's not the behaviour I would expect to see, and I've just put together a small test case which prints a message in the addingService, removedService and modifiedService methods of the ServiceTracker. When I update the bundle that registered the service, I see the following: osgi update 5 Removed service Added service osgi Which seems to be the way it should work. I suggest posting a message to the equinox-dev mailing list ( https://dev.eclipse.org/mailman/listinfo/equinox-dev) explaining the problem in detail and including a minimal code sample that reproduces the problem. Regards, Neil On 25 Jan 2008, at 13:42, Mark wrote: Neil, First off I have to thank you in a big way, because it was you articles that got me up and running on OSGI. I am also glad that you are putting together a book... because I was thinking about it myself...in practice or in action!, would you like some help? ..Anyway the reason for this mail... I was looking at the Listeners Considered Harmful: The Whiteboard Pattern white paper, and I put together a very simple two bundle example (on Equinox), Bundle A (offers a service) Bundle B (consumes service A, using a Service Tracker) So far so good, and not exactly rocket science. However this morning I discovered that if you update A - then you must refresh A in order for B to receive the added service event. This came as a surprise, go I Googled a while, and came up short. So I was wondering if you had some words of widom for me on this ? Kind Regards Mark ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] is this a service tracker bug?
Try adding: Import-Package: bundlea.service to the Bundle A manifest. Then when bundle A is updated to A', A' will import the package from A which is where bundle B is importing it. So bundle B can see the service from A' since it implements the interface from A. (This follows from Tom Watson's explanation.) See http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] is this a service tracker bug?
Mark, This is because of the pending removal of the old class loader from bundle A which bundle B is still wired to for package bundlea.service. You do not see the new service from bundle B because you would get a ClassCastException. The Framework filters out services that it knows you do not have the correct package wiring for. The new content for the service is loaded from the new class loader of Bundle A. But since Bundle B is still wired to the old content of Bundle A it will not see the service until it is refreshed. A refresh operation will rewire Bundle B so that it gets the new content from Bundle A and everybody will be happy. Tom [EMAIL PROTECTED] wrote on 01/25/2008 10:33:33 AM: This is driving me mad. I have two bundles A and B. B track the service offered by A. However if I call update on A then I get a remove Service notification but no add Service notification - that is until I issue a refresh command ? is this a bug? I have written the same simple code 10 time .. see the results. I have attached the two bundles and the two eclipse plugin projects (as one zip) - just in case a Eclipse/OSGi guru like yourself can figure it out? [image removed] [image removed] C:\egjava -jar equinox.osgi.jar -console osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 osgi install file:bundleA_1.0.0.jar Bundle id is 1 osgi install file:bundleB_1.0.0.jar Bundle id is 2 osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 1 INSTALLED bundleA_1.0.0 2 INSTALLED bundleB_1.0.0 osgi start 1 osgi start 2 addingService osgi stop 1 removedService osgi start 1 addingService osgi update 1 removedService - no add ! osgi stop 2 osgi start 2 osgi refresh - Only get add after refresh osgi addingService osgi On 25/01/2008, Neil Bartlett [EMAIL PROTECTED] wrote: Hi Mark, Many thanks for your kind words! Regarding the service tracker problem... that's not the behaviour I would expect to see, and I've just put together a small test case which prints a message in the addingService, removedService and modifiedService methods of the ServiceTracker. When I update the bundle that registered the service, I see the following: osgi update 5 Removed service Added service osgi Which seems to be the way it should work. I suggest posting a message to the equinox-dev mailing list ( https://dev.eclipse.org/ mailman/listinfo/equinox-dev) explaining the problem in detail and including a minimal code sample that reproduces the problem. Regards, Neil On 25 Jan 2008, at 13:42, Mark wrote: Neil, First off I have to thank you in a big way, because it was you articles that got me up and running on OSGI. I am also glad that you are putting together a book... because I was thinking about it myself...in practice or in action!, would you like some help? ..Anyway the reason for this mail... I was looking at the Listeners Considered Harmful: The Whiteboard Pattern white paper, and I put together a very simple two bundle example (on Equinox), Bundle A (offers a service) Bundle B (consumes service A, using a Service Tracker) So far so good, and not exactly rocket science. However this morning I discovered that if you update A - then you must refresh A in order for B to receive the added service event. This came as a surprise, go I Googled a while, and came up short. So I was wondering if you had some words of widom for me on this ? Kind Regards Mark [attachment bundleA_1.0.0.jar deleted by Thomas Watson/Austin/IBM] [attachment bundleB_1.0.0.jar deleted by Thomas Watson/Austin/IBM] [attachment eclipe-projects.zip deleted by Thomas Watson/Austin/IBM] ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] is this a service tracker bug?
Which is the prime reason why you should also import your service package in A, so that it can wire to other providers if they are available. - richard Jeremy Volkman wrote: Mark, Since your service interface (IA.java) is contained within bundleA, bundleB requires a package import from bundleA. The effect that you're seeing is that the old version of bundleA remains in the system and is still used by bundleB after you call update. Therefore you now have two instances of bundleA in the system: the old one, still used by bundleB, and the new refreshed one. Since you called 'refresh', the old bundleA was stopped, and so were any registered services (which is why you see 'removedService'). The new bundleA was also started, and a new IA service was registered. However, since bundleB is still using the package import from the old bundleA, it does not get notified of the new bundleA's service (refer to ServiceListener vs. AllServiceListener). Calling 'refresh' instructs the framework to perform the steps outlined at http://www2.osgi.org/javadoc/r4/org/osgi/service/packageadmin/PackageAdmin.html#refreshPackages(org.osgi.framework.Bundle[]). This in turn stops bundleB, gets rid of the old bundleA and links bundleB to the new bundleA's package source. When bundleB is restarted and linked to the new bundleA, it can once again see the IA service. Sorry if that was a bit confusing.. maybe someone else can clarify a bit more. -Jeremy On Jan 25, 2008 11:33 AM, Mark [EMAIL PROTECTED] wrote: This is driving me mad. I have two bundles A and B. B track the service offered by A. However if I call update on A then I get a remove Service notification but no add Service notification - that is until I issue a refresh command ? is this a bug? I have written the same simple code 10 time .. see the results. I have attached the two bundles and the two eclipse plugin projects (as one zip) - just in case a Eclipse/OSGi guru like yourself can figure it out? C:\egjava -jar equinox.osgi.jar -console osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 osgi install file:bundleA_1.0.0.jar Bundle id is 1 osgi install file:bundleB_1.0.0.jar Bundle id is 2 osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 1 INSTALLED bundleA_1.0.0 2 INSTALLED bundleB_1.0.0 osgi start 1 osgi start 2 addingService osgi stop 1 removedService osgi start 1 addingService osgi update 1 removedService - no add ! osgi stop 2 osgi start 2 osgi refresh - Only get add after refresh osgi addingService osgi On 25/01/2008, Neil Bartlett [EMAIL PROTECTED] wrote: Hi Mark, Many thanks for your kind words! Regarding the service tracker problem... that's not the behaviour I would expect to see, and I've just put together a small test case which prints a message in the addingService, removedService and modifiedService methods of the ServiceTracker. When I update the bundle that registered the service, I see the following: osgi update 5 Removed service Added service osgi Which seems to be the way it should work. I suggest posting a message to the equinox-dev mailing list ( https://dev.eclipse.org/mailman/listinfo/equinox-dev) explaining the problem in detail and including a minimal code sample that reproduces the problem. Regards, Neil On 25 Jan 2008, at 13:42, Mark wrote: Neil, First off I have to thank you in a big way, because it was you articles that got me up and running on OSGI. I am also glad that you are putting together a book... because I was thinking about it myself...in practice or in action!, would you like some help? ..Anyway the reason for this mail... I was looking at the Listeners Considered Harmful: The Whiteboard Pattern white paper, and I put together a very simple two bundle example (on Equinox), Bundle A (offers a service) Bundle B (consumes service A, using a Service Tracker) So far so good, and not exactly rocket science. However this morning I discovered that if you update A - then you must refresh A in order for B to receive the added service event. This came as a surprise, go I Googled a while, and came up short. So I was wondering if you had some words of widom for me on this ? Kind Regards Mark ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] is this a service tracker bug?
Matt, please open a bug against Equinox-Framework. I have reproduced, it appears to be related to lazy activation. If you remove the Eclipse-LazyStart header from Bundle A then it works. This is an interesting corner case we may need to get a clarification from OSGi on. I assume the old content of the bundle will not have access to a BundleContext. What does it mean to get wired to old pending removal content of a bundle that is lazy activated? The classes may be in an invalid state if they cannot have access to a BundleContext. Tom From: BJ Hargrave/Austin/[EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/25/2008 12:10 PM Subject:Re: [equinox-dev] is this a service tracker bug? But you should not have to refresh. That is the whole point of importing the package which is exported. So that A' can import it from A which is where B imports it from. I think the IllegalStateException is is a bug in Equinox. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mark [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008-01-25 13:06 Subject: Re: [equinox-dev] is this a service tracker bug? I see - It's in an IllegalState until you refresh On 25/01/2008, Mark [EMAIL PROTECTED] wrote: Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi stop 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37
