Not sure if that is possible...
I think it would be awesome if the DS runtime could try to load the
component class and if it fails because of an unwired package
it could simply choose to not instantiate the component. It could also
report this problem when you look into the components from the shell.
When the bundle is then refreshed later it could try the same again and
maybe succeed if the package is wired now.
The big advantage would be that the user would not have to code anything
to make this work.
Currently handling optional imports using an Activator is quite
difficult and error prone.
Does that make sense?
Christian
On 26.04.2017 00:06, Raymond Auge wrote:
You're not far off,
but clearly the component could not be implementing the missing package...
Let's say we have an API:
interface com.foo.Provider {
public void provide();
}
a bundle wants to provide an implementation of this API:
@Component
class FancyProviderImpl implements com.foo.Provider { ... }
However the goal of FancyProviderImpl is to deliver functionality by
using fancy-lib.jar which is a second bundle.
e.g.
import fancy.lib.Thing;
@Component
class FancyProviderImpl implements com.foo.Provider {
public void provide() {
new Thing().doSomethingFancy();
}
}
I'd like for the bundle containing FancyProviderImpl to have an
optional import on `fancy.lib`, and not blow up when `fancy-lib.jar`
is not deployed. Exactly the same scenario you mentioned with
configAdmin, metatype and SCR.
I hope that makes sense,
- Ray
On Tue, Apr 25, 2017 at 5:51 PM, Felix Meschberger <fmesc...@adobe.com
<mailto:fmesc...@adobe.com>> wrote:
Hi Ray
I am not sure, I understand the question.
Are you asking that the component dynamically decides to register
as a certain service depending on the whether a certain package is
wired ?
I think that does not work as the component implements an
interface which is the service name and the component class can
only be loaded if the class object representing the interface
being implemented is accessible, otherwise a Linkage error occurrs.
Or may I am on the wrong track alltogether.
Regards
Felix
Am 25.04.2017 um 14:46 schrieb Raymond Auge
<raymond.a...@liferay.com <mailto:raymond.a...@liferay.com>>:
Thank you Felix, I agree and understand all of what you are saying.
However, what I'm wondering though is if anyone has come up with
a design pattern where a DS component can determine
programmatically whether it (or a peer component it controls)
should be provided as a service based on the check for some
optional package.
Sincerely,
- Ray
On Tue, Apr 25, 2017 at 5:33 PM, Felix Meschberger
<fmesc...@adobe.com <mailto:fmesc...@adobe.com>> wrote:
Hi
You mean dynamic imports due to optional dependencies ?
I think the key is to limit them. If I remember correctly I
have (or had) some of this in the Apache Felix SCR
implementation around the Metatype and Configuration Admin
dependencies.
What I do is I hand-craft a DynamicImport-Package statement
for the exact package along with the packages import version
range. Then, unless the service is provided, the package may
not be resolved.
I generally also have fields, but as long as I don’t access
that field other than checking for null, the dependency is
not needed either.
This works great, but I try to reduce such uses to the
absolute minimum because it involves manual work.
Hope this helps
Regards
Felix
Am 25.04.2017 um 14:10 schrieb Raymond Auge
<raymond.a...@liferay.com <mailto:raymond.a...@liferay.com>>:
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
<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
<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
<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
<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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
