I totally agree that a clean solution would be to extract the service in another bundle with a non optional dependency, as this avoids any runtime issues at the beginning by not starting the bundle. Will think about that for the Platform Runtime after Oxygen, as such a change is not allowed at the current state of the development.
Nevertheless I created https://bugs.eclipse.org/bugs/show_bug.cgi?id=515873 because the NPE is misleading. Whether an exception should be shown or not is discussable. Felix is not showing anything at all, which also makes it hard to find the reason why the service is not activated. Therefore logging the exception is perfectly fine in my opinion. But the NPE when using the field strategy looks incorrect to me. It doesn’t help anyway to find the real cause. Mit freundlichen Grüßen / Best regards Dirk Fauth Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | www.bosch.com<http://www.bosch.com> Tel. +49(7153)666-1155 | dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner, Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] Im Auftrag von Thomas Watson Gesendet: Mittwoch, 26. April 2017 14:38 An: osgi-dev@mail.osgi.org Betreff: Re: [osgi-dev] handling optional/dynamic imports in DS By Private-Package Peter means he packages the optional package internally in the bundle but also optionally imports it so that if it is resolved to an external provider then that will be used over the internal copy. The Private-Package header in bnd will instruct bnd to package the package internally in the jar. Personally, if I had this scenario I would extract the service component out to a new bundle that has a non-optional import for the package and be done with the magic of dynamic or optional imports. Or if that is not what you want I would make it a fragment the that has a non-optional import. That way the bundle with the service component cannot possibly provide its service component until it is resolved. I'm not sure I follow your example that is failing in equinox, but open a bug if you find it is an Equinox bug. Tom ----- Original message ----- From: "Fauth Dirk (AA-AS/EIS2-EU)" <dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com>> Sent by: osgi-dev-boun...@mail.osgi.org<mailto:osgi-dev-boun...@mail.osgi.org> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org>> Cc: Subject: Re: [osgi-dev] handling optional/dynamic imports in DS Date: Wed, Apr 26, 2017 3:02 AM Interestingly this works fine when running from Bndtools with Felix. If I try the same with Equinox for projects created with PDE I get a NullPointerException. IIRC Private-Package is something special to Bnd. Is that correct? I wonder if that exception is caused by some PDE flaws or if it is an issue in Equinox Oxygen. In both cases Apache Felix SCR 2.0 is used. (in Oxygen 2.0.8 and in Bndtools 2.0.2) org.osgi.framework.ServiceException: Exception in org.apache.felix.scr.impl.manager.SingleComponentManager.getService() at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:222) at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111) at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:508) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461) at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:624) at org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72) at org.apache.felix.scr.impl.inject.FieldHandler$ReferenceMethodImpl.getServiceObject(FieldHandler.java:985) at org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2201) at org.apache.felix.scr.impl.manager.DependencyManager$MultipleStaticReluctantCustomizer.prebind(DependencyManager.java:699) at org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1520) at org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1006) at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:859) at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823) at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210) at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111) at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:508) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461) at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:624) at org.apache.felix.gogo.runtime.CommandProxy.getTarget(CommandProxy.java:50) at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:72) at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477) at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403) at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120) at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89) at org.apache.felix.gogo.shell.Console.run(Console.java:62) at org.apache.felix.gogo.shell.Shell.console(Shell.java:203) at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:128) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137) at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82) at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477) at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403) at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120) at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89) at org.apache.felix.gogo.shell.Activator.run(Activator.java:75) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NullPointerException at org.apache.felix.scr.impl.inject.FieldHandler.validateField(FieldHandler.java:279) at org.apache.felix.scr.impl.inject.FieldHandler.access$500(FieldHandler.java:51) at org.apache.felix.scr.impl.inject.FieldHandler$NotResolved.resolve(FieldHandler.java:839) at org.apache.felix.scr.impl.inject.FieldHandler$NotResolved.fieldExists(FieldHandler.java:864) at org.apache.felix.scr.impl.inject.FieldHandler.fieldExists(FieldHandler.java:918) at org.apache.felix.scr.impl.inject.FieldHandler$3.init(FieldHandler.java:1018) at org.apache.felix.scr.impl.manager.DependencyManager.invokeInitMethod(DependencyManager.java:1657) at org.apache.felix.scr.impl.manager.DependencyManager.open(DependencyManager.java:1533) at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:261) at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:109) at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:906) at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:879) at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823) at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210) ... 46 more Mit freundlichen Grüßen / Best regards Dirk Fauth Automotive Service Solutions, ESI application (AA-AS/EIS2-EU) Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY | www.bosch.com<http://www.bosch.com> Tel. +49(7153)666-1155 | dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner, Prof. Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller Von: osgi-dev-boun...@mail.osgi.org<mailto:osgi-dev-boun...@mail.osgi.org> [mailto:osgi-dev-boun...@mail.osgi.org] Im Auftrag von Peter Kriens Gesendet: Mittwoch, 26. April 2017 09:14 An: OSGi Developer Mail List <osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org>> Betreff: Re: [osgi-dev] handling optional/dynamic imports in DS I used to import the package optional and then provide it as an internal Private-Package. The import has priority but the internal package is used when the import fails to resolve. Since you’re then always wired to a package you can handle dependencies on the place they should be handled: services. This keeps everybody happy internally for very little cost. I’ve included a bndtools/enRoute example. Kind regards, Peter Kriens ————————————————— bnd.bnd Private-Package: \ org.osgi.service.cm,\ com.foo.provider Import-Package: \ org.osgi.service.cm;resolution:=optional,\ * -buildpath: \ osgi.enroute.base.api -runrequires: \ osgi.identity;filter:='(osgi.identity=com.foo.provider)',\ osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.runtime)',\ osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\ osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)' -runbundles: \ com.foo.provider;version=snapshot,\ org.apache.felix.log;version='[1.0.1,1.0.2)',\ org.apache.felix.scr;version='[2.0.2,2.0.3)',\ org.apache.felix.gogo.runtime,\ org.apache.felix.gogo.shell;version=0.16 ————————————————— com.foo.provider.Optional @Component public class Optional { @Reference(cardinality=ReferenceCardinality.OPTIONAL) ConfigurationAdmin admin; @Activate void activate() { System.out.println("activate " + admin); } } On 25 Apr 2017, at 23:10, Raymond Auge <raymond.a...@liferay.com<mailto:raymond.a...@liferay.com>> wrote: I'm wondering if there is a reasonable model for handling optional or dynamic package imports in DS. While optionality at the package level is not an ideal model, sometimes it can't be avoided. I'd like to know if others have come across a "reasonable" way to model this in DS. Sincerely, -- Raymond Augé<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect Liferay, Inc.<http://www.liferay.com/> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance<http://osgi.org/> (@OSGiAlliance) _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
