Hi Benson,
I agree: we had a long discussion with Guillaume about that in the past ;)
As a workaround, you can use the feature capability definition (and it
can be done at runtime using feature:* commands). So your DS components
don't have to change.
Regards
JB
On 08/31/2016 03:30 PM, Benson Margulies wrote:
Gentlemen,
Thank you very much for the help. I want to offer a small argument for
an option to turn all this off in a CFG file, before I get to work
using the solutions you've offered.
One of the virtues of DS is that you can mix-and-match: a DS component
can transparently use non-DS services. This resolver feature disables
that nice transparency by requiring any service used in a DS component
to be accounted for in a Provide-Capability. So you might accept the
proposition that this resolver enforcement is not so good for
everyone.
--benson
On Wed, Aug 31, 2016 at 6:13 AM, Guillaume Nodet <gno...@apache.org> wrote:
2016-08-31 15:00 GMT+02:00 Benson Margulies <ben...@basistech.com>:
On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:
So, I will explain a new time (for the third time ;)).
JB,
I apologize for not being awake when this came through before.
I just want to make sure that I am completely following this. The
resolver is requiring that some bundle mentions the service in a
Provide-Capability -- NOT that the service is actually running?
The resolver looks at the bundle manifest. It runs before they are installed
/ started, so it can't really look at if they are running or not.
The service in question is provided by an 'old' OSGi bundle that does
not bother to do a Provide-Capability for it; it's not a service, just
a service launched the old-fashioned way.
Is there some thread you can point me to that offers suggestions for
dealing with this? I would rather not have to go add
Provide-Capability manifest entries for all my dynamically created
OSGi services. Is there an option in a cfg file or a feature.xml that
turns this back off?
This could be done for karaf 4.1 with a new xsd.
Perhaps I can persuade BND not to list them as requirements.
Yeah, that's definitely the easiest way, you can easily remove the
Require-Capability header, or disable the service requirements, depending on
how they are generated.
Thanks,
benson
When you are using features XML with namespace 1.3 or 1.4, the feature
resolver uses the service enforcement. It means that it checks the
service
capability in the bundles. The service requirement is basically a bundle
that needs a service "A" at runtime. So the resolver will check the
features
containing the bundle providing such capability (exposing the service).
It's
what the effective:=active mean.
The corresponding MANIFEST header is:
<Provide-Capability>
osgi.service;effective:=active;objectClass=myService
</Provide-Capability>
On the other hand, the requirement header looks like:
<Require-Capability>
osgi.service;effective:=active;filter:="(objectClass=aService)"
</Require-Capability>
Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the service enforcement was
enabled for features xmlns 1.3.0 NOT for 1.4.0 (it was a bug). This bug
has
been fixed in Karaf 4.0.6. That's why when you upgraded from 4.0.4 to
4.0.6,
the feature resolver is now "active" for your features XML and check the
service enforcement.
Regards
JB
On 08/31/2016 02:31 PM, Benson Margulies wrote:
I just tried the experiment of moving our platform from 4.0.4 to
4.0.6, changing nothing but the karaf version. I received in return a
resolution error that I've never seen the like of before, complaining
that a particular service is missing with 'effective:=active'.
Since Karaf does not come to command level when this sort of thing
goes wrong, it is not obvious to me how to gain any insight into what
is wrong. The service reference itself is very strange;
'RosetteBundleWarmup' a DS reference like:
@Reference(target = "(component-name=name-matching)")
public void setWarmup(RosetteBundleWarmup warmup) {
this.componentWarmup = warmup;
}
and I don't see the component-name filter in the error message. It's
also new to me that DS @Reference is even visible to resolution at the
time that boot features are being resolved.
2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1 |
BootFeaturesInstaller | 6 - org.apache.karaf.features.core
- 4.0.6 | Error installing boot features
org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity;
osgi.identity=rosapi-all-sdks; type=karaf.feature;
version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
[caused by: Unable to resolve rosapi-all-sdks/1.2.6.SNAPSHOT: missing
requirement [rosapi-all-sdks/1.2.6.SNAPSHOT] osgi.identity;
osgi.identity=rosapi-worker-rni-rnt-sdk; type=karaf.feature [caused
by: Unable to resolve rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
missing requirement [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
osgi.identity;
osgi.identity=com.basistech.ws.rosapi-worker-rni-rnt-sdk;
type=osgi.bundle;
version="[1.2.6.v20160831122227,1.2.6.v20160831122227]";
resolution:=mandatory [caused by: Unable to resolve
com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227:
missing requirement
[com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v20160831122227]
osgi.service;
filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
effective:=active]]]
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
