Interesting approach!
But I think it is not necessary to say "@Component(service={})". As the
OptionalPackageConsumerStarter does not implement an interface it is an
immediate component by default. Setting service={} would only make it explicit.
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 Raymond Auge
Gesendet: Montag, 1. Mai 2017 20:13
An: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Betreff: Re: [osgi-dev] handling optional/dynamic imports in DS
Good points BJ! I'll put an App Note together for this.
- Ray
On Mon, May 1, 2017 at 2:07 PM, BJ Hargrave
<hargr...@us.ibm.com<mailto:hargr...@us.ibm.com>> wrote:
Also, the controller component should not register a service.
"@Component(service={})". If you say "service={}" then you are "immediate=true".
Maybe you should make an enroute app note for this?
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848
1781<tel:(386)%20848-1781>
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848
3788<tel:(386)%20848-3788>
hargr...@us.ibm.com<mailto:hargr...@us.ibm.com>
----- Original message -----
From: Raymond Auge <raymond.a...@liferay.com<mailto:raymond.a...@liferay.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: Mon, May 1, 2017 2:04 PM
Good one Tim!
Oh, and I forgot to show that the "controller" component should be immediate
otherwise it will never activate since nothing should "use" it.
- Ray
On Mon, May 1, 2017 at 1:31 PM, Tim Ward
<tim.w...@paremus.com<mailto:tim.w...@paremus.com>> wrote:
For a dynamic import your controller could register a listener so that when a
suitable package appears in the runtime your disabled component gets activated
without needing to restart the controller.
Tim
Sent from my iPhone
On 1 May 2017, at 17:41, Raymond Auge
<raymond.a...@liferay.com<mailto:raymond.a...@liferay.com>> wrote:
Hey All,
I managed to find a relatively elegant solution to this with pure DS.
Given a component using an optional/dynamic package(s):
import com.liferay.demo.foo.Foo; // The optional package
@Component(
enabled = false // disable so that DS ignores it
)
public class OptionalPackageConsumer implements Foo {...}
A controller is created which does the classloader check:
@Component
public class OptionalPackageConsumerStarter {
@Activate
void activate(ComponentContext componentContext) {
try {
Class.forName(com.liferay.demo.foo.Foo.class.getName());
componentContext.enableComponent(OptionalPackageConsumer.class.getName());
}
catch (Throwable t) {
_log.warn("Could not find {}", t.getMessage());
}
}
}
If successful, the component is enabled, otherwise, don't!
- Ray
On Thu, Apr 27, 2017 at 1:48 AM, Fauth Dirk (AA-AS/EIS2-EU)
<dirk.fa...@de.bosch.com<mailto:dirk.fa...@de.bosch.com>> wrote:
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<tel:+49%207153%206661155> |
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<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<mailto: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.ge<http://iceregistry.ServiceRegistry.ge>tService(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.ge<http://iceregistry.ServiceRegistry.ge>tService(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.Co<http://org.apache.felix.gogo.shell.Co>nsole.run(Console.java:62)
at
org.apache.felix.gogo.shell.Sh<http://org.apache.felix.gogo.shell.Sh>ell.console(Shell.java:203)
at
org.apache.felix.gogo.shell.Sh<http://org.apache.felix.gogo.shell.Sh>ell.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.Ac<http://org.apache.felix.gogo.shell.Ac>tivator.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<tel:+49%207153%206661155> |
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<http://org.osgi.service.cm>,\
com.foo.provider
Import-Package: \
org.osgi.service.cm<http://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<mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
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
--
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
--
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
https://mail.osgi.org/mailman/listinfo/osgi-dev
