You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by "Leschke, Scott" <SL...@medline.com> on 2020/12/03 15:04:26 UTC

RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

Hi JB,

I’m curious if you have any info on the issue below.  I tested using HotSpot and got the same result.  As I’ve mentioned, I find this particularly perplexing as one of the packages that gets flagged is java.lang.

Is there anything you’d like me to try on my end regarding this?

Scott Leschke

From: Leschke, Scott <SL...@medline.com>
Sent: Monday, November 16, 2020 7:54 AM
To: user@karaf.apache.org
Subject: RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
Yes, I apologize. I’m running openjdk 14.whatever and the OpenJ9 VM.  Perhaps it’s J9.  When I saw this issue previously, with 4.2.10 I believe, I think I was using openjdk 11 and J9.

Scott

From: Jean-Baptiste Onofre <jb...@nanthrax.net>>
Sent: Monday, November 16, 2020 1:13 AM
To: user@karaf.apache.org<ma...@karaf.apache.org>
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
I just checked on java.specification.version is 14, so it’s fine.

I also checked with JDK 14.0.1 on Mac and it works fine (at least for Karaf examples).

I’m checking on Windows VM.

Regards
JB

Le 2 nov. 2020 à 01:48, Leschke, Scott <SL...@medline.com>> a écrit :

Karaf 4.3.0 on Windows, JDK 14.   All java.* packages, including java.lang, show as Unsatisfied Requriements in bundle:diag output.  Setting
karaf.framework=equinox
yields similar results.

org.osgi.framework.BundleException: Unable to resolve medline.bam.provider.jdbc [181](R 181.0): missing requirement [medline.bam.provider.jdbc [181](R 181.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0))) [caused by: Unable to resolve medline.osgi [169](R 169.0): missing requirement [medline.osgi [169](R 169.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.util.service)(version>=1.0.0)(!(version>=2.0.0))) [caused by: Unable to resolve medline.util [163](R 163.0): missing requirement [medline.util [163](R 163.0)] osgi.wiring.package; (osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!q6M6Du7f0xiSnnAzLzvUs3aLfck7r20ezWQc7Q_why5WXrRefvh1fiGcgNFV4xk$>)]] Unresolved requirements: [[medline.bam.provider.jdbc [181](R 181.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0)))]
               at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
               at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) ~[?:?]
….

Scott

RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

Posted by "Leschke, Scott" <SL...@medline.com>.
JB, here’s the scr .xml.  I will try to put together simplified bundle that exhibits the behavior by the weekend.

Thx, Scott

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.3.0" name="com.medline.bam.schedule.ScheduleFactory" immediate="true">
  <property name="name" type="String" value="default"/>
  <service>
    <provide interface="com.medline.bam.api.schedule.IScheduleFactory"/>
  </service>
  <implementation class="com.medline.bam.schedule.ScheduleFactory"/>
</scr:component>

From: Jean-Baptiste Onofre <jb...@nanthrax.net>
Sent: Monday, December 14, 2020 11:25 PM
To: user@karaf.apache.org
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
Hi,

The MANIFEST doesn’t look good to me. For instance, Private-Package doesn’t really exists from a framework standpoint.

A the issue comes directly from the framework when it tries to load the bundle (nothing related with Karaf here), and I don’t see java.lang import at all in your bundle. Can you check the content of SCR XML ?

You mentioned you didn’t change etc/jre.properties or etc/config.properties, so java.lang is exported by bundle 0 for sure (the framework).

IMHO, something wrong with bndtools here (I don’t use it).

Can you create a very simple bundle with bndtools and provide to me ? I will test.

Regards
JB


Le 15 déc. 2020 à 01:21, Leschke, Scott <SL...@medline.com>> a écrit :

Today, I tried to update one of the bundle on my 4.2.8 installation (my production). This if running on Java 1.8 on Windows.  It failed to deploy with the following :

2020-12-14T12:14:57,125 | ERROR | fileinstall-C:/BAM | Felix                            | 5 - org.ops4j.pax.logging.pax-logging-api - 1.11.4 | Bundle medline.bam.schedule [167] Unable to update the bundle. (org.osgi.framework.BundleException: Importing java.* packages not allowed: java.lang)
org.osgi.framework.BundleException: Importing java.* packages not allowed: java.lang
               at org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeImportClauses(ManifestParser.java:349) ~[org.apache.felix.framework-5.6.12.jar:?]
               at org.apache.felix.framework.util.manifestparser.ManifestParser.<init>(ManifestParser.java:181) ~[org.apache.felix.framework-5.6.12.jar:?]
               at org.apache.felix.framework.BundleRevisionImpl.<init>(BundleRevisionImpl.java:117) ~[org.apache.felix.framework-5.6.12.jar:?]
               at org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1282) ~[org.apache.felix.framework-5.6.12.jar:?]
               at org.apache.felix.framework.BundleImpl.revise(BundleImpl.java:1219) ~[org.apache.felix.framework-5.6.12.jar:?]
               at org.apache.felix.framework.Felix.updateBundle(Felix.java:2388) [org.apache.felix.framework-5.6.12.jar:?]
….

What this and the issue using 4.3.0 have is that I’m using BndTools 5.2.0 in both to generate my bundles.  This is the manifest of the bundle that failed.  Looks OK to me but perhaps there’s something subtle that shouldn’t be there?  All input appreciated.

Regards,
Scott

Manifest-Version: 1.0
Bnd-LastModified: 1607977206683
Bundle-ManifestVersion: 2
Bundle-Name: Medline BAM Model Schedule
Bundle-SymbolicName: medline.bam.schedule
Bundle-Version: 1.0.0.202012142020
Created-By: 14.0.2 (Oracle Corporation)
Export-Package: com.medline.bam.api;version="1.0.0";uses:="com.medline
.bam.api.metric,com.medline.bam.api.provider,com.medline.bam.api.repo
rt,com.medline.util.model.identifier,com.medline.util.query.jdbc,com.
medline.util.service,org.slf4j",com.medline.bam.api.metric;version="1
.0.0";uses:="com.medline.bam.api.provider",com.medline.bam.api.provid
er;version="1.0.0";uses:="com.medline.bam.api,com.medline.bam.api.met
ric,com.medline.bam.api.rule,com.medline.bam.api.schedule,com.medline
.util.query.api,com.medline.util.service,org.slf4j",com.medline.bam.a
pi.report;version="1.0.0";uses:="com.medline.bam.api,com.medline.util
.query.api,com.medline.util.query.http,com.medline.util.query.jdbc,co
m.medline.util.service",com.medline.bam.api.rule;version="1.0.0";uses
:="com.medline.bam.api,com.medline.bam.api.metric,com.medline.bam.api
.provider,com.medline.bam.api.schedule",com.medline.bam.api.schedule;
version="1.0.0";uses:="com.medline.util.model"
Git-Descriptor: 23996f2-dirty
Git-SHA: 23996f202ab9237416af1a4c35c209751d907c47
Import-Package: com.medline.bam.api;version="[1.0,2)",com.medline.bam.
api.metric;version="[1.0,2)",com.medline.bam.api.provider;version="[1
.0,2)",com.medline.bam.api.report;version="[1.0,2)",com.medline.bam.a
pi.rule;version="[1.0,2)",com.medline.bam.api.schedule;version="[1.0,
2)",com.medline.util,com.medline.util.model;version="[1.0,2)",com.med
line.util.model.identifier;version="[1.0,2)",com.medline.util.query.a
pi,com.medline.util.query.http,com.medline.util.query.jdbc,com.medlin
e.util.service,org.apache.commons.lang3;version="[3.4,4)",org.slf4j
Private-Package: com.medline.bam.schedule
Provide-Capability: osgi.service;objectClass:List<String>="com.medline
.bam.api.schedule.IScheduleFactory";uses:="com.medline.bam.api.schedu
le"
Require-Capability: osgi.extender;filter:="(&(osgi.extender=osgi.compo
nent)(version>=1.3.0)(!(version>=2.0.0)))",osgi.ee;filter:="(&(osgi.e
e=JavaSE)(version=1.8))"
Service-Component: OSGI-INF/com.medline.bam.schedule.ScheduleFactory.x
ml
Tool: Bnd-5.2.0.202010142003

From: Jean-Baptiste Onofre <jb...@nanthrax.net>>
Sent: Thursday, December 03, 2020 9:52 AM
To: user@karaf.apache.org<ma...@karaf.apache.org>
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
Hi Scott,

I’m not able to reproduce your issue (neither on MacOS or Linux (Debian, Ubuntu), nor on Jenkins).

I tested with adatjdk and oracle jdk. I will download test with OpenJDK (it should be pretty close to Adapt).

Regards
JB



Le 3 déc. 2020 à 16:04, Leschke, Scott <SL...@medline.com>> a écrit :

Hi JB,
I’m curious if you have any info on the issue below. I tested using HotSpot and got the same result. As I’ve mentioned, I find this particularly perplexing as one of the packages that gets flagged is java.lang.
Is there anything you’d like me to try on my end regarding this?
Scott Leschke
From: Leschke, Scott <SL...@medline.com>>
Sent: Monday, November 16, 2020 7:54 AM
To: user@karaf.apache.org<ma...@karaf.apache.org>
Subject: RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
Yes, I apologize. I’m running openjdk 14.whatever and the OpenJ9 VM. Perhaps it’s J9. When I saw this issue previously, with 4.2.10 I believe, I think I was using openjdk 11 and J9.
Scott
From: Jean-Baptiste Onofre <jb...@nanthrax.net>>
Sent: Monday, November 16, 2020 1:13 AM
To: user@karaf.apache.org<ma...@karaf.apache.org>
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
I just checked on java.specification.version is 14, so it’s fine.
I also checked with JDK 14.0.1 on Mac and it works fine (at least for Karaf examples).
I’m checking on Windows VM.
Regards
JB
Le 2 nov. 2020 à 01:48, Leschke, Scott <SL...@medline.com>> a écrit :
Karaf 4.3.0 on Windows, JDK 14. All java.* packages, including java.lang, show as Unsatisfied Requriements in bundle:diag output. Setting
karaf.framework=equinox
yields similar results.
org.osgi.framework.BundleException: Unable to resolve medline.bam.provider.jdbc [181](R 181.0): missing requirement [medline.bam.provider.jdbc [181](R 181.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0))) [caused by: Unable to resolve medline.osgi [169](R 169.0): missing requirement [medline.osgi [169](R 169.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.util.service)(version>=1.0.0)(!(version>=2.0.0))) [caused by: Unable to resolve medline.util [163](R 163.0): missing requirement [medline.util [163](R 163.0)] osgi.wiring.package; (osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!q6M6Du7f0xiSnnAzLzvUs3aLfck7r20ezWQc7Q_why5WXrRefvh1fiGcgNFV4xk$>)]] Unresolved requirements: [[medline.bam.provider.jdbc [181](R 181.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0)))]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) ~[?:?]
….
Scott

Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi,

The MANIFEST doesn’t look good to me. For instance, Private-Package doesn’t really exists from a framework standpoint.

A the issue comes directly from the framework when it tries to load the bundle (nothing related with Karaf here), and I don’t see java.lang import at all in your bundle. Can you check the content of SCR XML ?

You mentioned you didn’t change etc/jre.properties or etc/config.properties, so java.lang is exported by bundle 0 for sure (the framework).

IMHO, something wrong with bndtools here (I don’t use it).

Can you create a very simple bundle with bndtools and provide to me ? I will test.

Regards
JB

> Le 15 déc. 2020 à 01:21, Leschke, Scott <SL...@medline.com> a écrit :
> 
> Today, I tried to update one of the bundle on my 4.2.8 installation (my production). This if running on Java 1.8 on Windows.  It failed to deploy with the following :
>  
> 2020-12-14T12:14:57,125 | ERROR | fileinstall-C:/BAM | Felix                            | 5 - org.ops4j.pax.logging.pax-logging-api - 1.11.4 | Bundle medline.bam.schedule [167] Unable to update the bundle. (org.osgi.framework.BundleException: Importing java.* packages not allowed: java.lang)
> org.osgi.framework.BundleException: Importing java.* packages not allowed: java.lang
>                at org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeImportClauses(ManifestParser.java:349) ~[org.apache.felix.framework-5.6.12.jar:?]
>                at org.apache.felix.framework.util.manifestparser.ManifestParser.<init>(ManifestParser.java:181) ~[org.apache.felix.framework-5.6.12.jar:?]
>                at org.apache.felix.framework.BundleRevisionImpl.<init>(BundleRevisionImpl.java:117) ~[org.apache.felix.framework-5.6.12.jar:?]
>                at org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1282) ~[org.apache.felix.framework-5.6.12.jar:?]
>                at org.apache.felix.framework.BundleImpl.revise(BundleImpl.java:1219) ~[org.apache.felix.framework-5.6.12.jar:?]
>                at org.apache.felix.framework.Felix.updateBundle(Felix.java:2388) [org.apache.felix.framework-5.6.12.jar:?]
> ….
>  
> What this and the issue using 4.3.0 have is that I’m using BndTools 5.2.0 in both to generate my bundles.  This is the manifest of the bundle that failed.  Looks OK to me but perhaps there’s something subtle that shouldn’t be there?  All input appreciated.
>  
> Regards,
> Scott
>  
> Manifest-Version: 1.0
> Bnd-LastModified: 1607977206683
> Bundle-ManifestVersion: 2
> Bundle-Name: Medline BAM Model Schedule
> Bundle-SymbolicName: medline.bam.schedule
> Bundle-Version: 1.0.0.202012142020
> Created-By: 14.0.2 (Oracle Corporation)
> Export-Package: com.medline.bam.api;version="1.0.0";uses:="com.medline
> .bam.api.metric,com.medline.bam.api.provider,com.medline.bam.api.repo
> rt,com.medline.util.model.identifier,com.medline.util.query.jdbc,com.
> medline.util.service,org.slf4j",com.medline.bam.api.metric;version="1
> .0.0";uses:="com.medline.bam.api.provider",com.medline.bam.api.provid
> er;version="1.0.0";uses:="com.medline.bam.api,com.medline.bam.api.met
> ric,com.medline.bam.api.rule,com.medline.bam.api.schedule,com.medline
> .util.query.api,com.medline.util.service,org.slf4j",com.medline.bam.a
> pi.report;version="1.0.0";uses:="com.medline.bam.api,com.medline.util
> .query.api,com.medline.util.query.http,com.medline.util.query.jdbc,co
> m.medline.util.service",com.medline.bam.api.rule;version="1.0.0";uses
> :="com.medline.bam.api,com.medline.bam.api.metric,com.medline.bam.api
> .provider,com.medline.bam.api.schedule",com.medline.bam.api.schedule;
> version="1.0.0";uses:="com.medline.util.model"
> Git-Descriptor: 23996f2-dirty
> Git-SHA: 23996f202ab9237416af1a4c35c209751d907c47
> Import-Package: com.medline.bam.api;version="[1.0,2)",com.medline.bam.
> api.metric;version="[1.0,2)",com.medline.bam.api.provider;version="[1
> .0,2)",com.medline.bam.api.report;version="[1.0,2)",com.medline.bam.a
> pi.rule;version="[1.0,2)",com.medline.bam.api.schedule;version="[1.0,
> 2)",com.medline.util,com.medline.util.model;version="[1.0,2)",com.med
> line.util.model.identifier;version="[1.0,2)",com.medline.util.query.a
> pi,com.medline.util.query.http,com.medline.util.query.jdbc,com.medlin
> e.util.service,org.apache.commons.lang3;version="[3.4,4)",org.slf4j
> Private-Package: com.medline.bam.schedule
> Provide-Capability: osgi.service;objectClass:List<String>="com.medline
> .bam.api.schedule.IScheduleFactory";uses:="com.medline.bam.api.schedu
> le"
> Require-Capability: osgi.extender;filter:="(&(osgi.extender=osgi.compo
> nent)(version>=1.3.0)(!(version>=2.0.0)))",osgi.ee;filter:="(&(osgi.e
> e=JavaSE)(version=1.8))"
> Service-Component: OSGI-INF/com.medline.bam.schedule.ScheduleFactory.x
> ml
> Tool: Bnd-5.2.0.202010142003
>  
> From: Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> 
> Sent: Thursday, December 03, 2020 9:52 AM
> To: user@karaf.apache.org <ma...@karaf.apache.org>
> Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages
>  
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> Hi Scott,
>  
> I’m not able to reproduce your issue (neither on MacOS or Linux (Debian, Ubuntu), nor on Jenkins).
>  
> I tested with adatjdk and oracle jdk. I will download test with OpenJDK (it should be pretty close to Adapt).
>  
> Regards
> JB
> 
> 
> Le 3 déc. 2020 à 16:04, Leschke, Scott <SLeschke@medline.com <ma...@medline.com>> a écrit :
>  
> Hi JB,
> I’m curious if you have any info on the issue below. I tested using HotSpot and got the same result. As I’ve mentioned, I find this particularly perplexing as one of the packages that gets flagged is java.lang.
> Is there anything you’d like me to try on my end regarding this?
> Scott Leschke
> From: Leschke, Scott <SLeschke@medline.com <ma...@medline.com>> 
> Sent: Monday, November 16, 2020 7:54 AM
> To: user@karaf.apache.org <ma...@karaf.apache.org>
> Subject: RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> Yes, I apologize. I’m running openjdk 14.whatever and the OpenJ9 VM. Perhaps it’s J9. When I saw this issue previously, with 4.2.10 I believe, I think I was using openjdk 11 and J9.
> Scott
> From: Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> 
> Sent: Monday, November 16, 2020 1:13 AM
> To: user@karaf.apache.org <ma...@karaf.apache.org>
> Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> I just checked on java.specification.version is 14, so it’s fine.
> I also checked with JDK 14.0.1 on Mac and it works fine (at least for Karaf examples).
> I’m checking on Windows VM.
> Regards
> JB
> Le 2 nov. 2020 à 01:48, Leschke, Scott <SLeschke@medline.com <ma...@medline.com>> a écrit :
> Karaf 4.3.0 on Windows, JDK 14. All java.* packages, including java.lang, show as Unsatisfied Requriements in bundle:diag output. Setting
> karaf.framework=equinox
> yields similar results.
> org.osgi.framework.BundleException: Unable to resolve medline.bam.provider.jdbc [181](R 181.0): missing requirement [medline.bam.provider.jdbc [181](R 181.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0))) [caused by: Unable to resolve medline.osgi [169](R 169.0): missing requirement [medline.osgi [169](R 169.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.util.service)(version>=1.0.0)(!(version>=2.0.0))) [caused by: Unable to resolve medline.util [163](R 163.0): missing requirement [medline.util [163](R 163.0)] osgi.wiring.package; (osgi.wiring.package=java.io <https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!q6M6Du7f0xiSnnAzLzvUs3aLfck7r20ezWQc7Q_why5WXrRefvh1fiGcgNFV4xk$>)]] Unresolved requirements: [[medline.bam.provider.jdbc [181](R 181.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0)))]
> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) ~[?:?]
> ….
> Scott

RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

Posted by "Leschke, Scott" <SL...@medline.com>.
Today, I tried to update one of the bundle on my 4.2.8 installation (my production). This if running on Java 1.8 on Windows.  It failed to deploy with the following :

2020-12-14T12:14:57,125 | ERROR | fileinstall-C:/BAM | Felix                            | 5 - org.ops4j.pax.logging.pax-logging-api - 1.11.4 | Bundle medline.bam.schedule [167] Unable to update the bundle. (org.osgi.framework.BundleException: Importing java.* packages not allowed: java.lang)
org.osgi.framework.BundleException: Importing java.* packages not allowed: java.lang
               at org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeImportClauses(ManifestParser.java:349) ~[org.apache.felix.framework-5.6.12.jar:?]
               at org.apache.felix.framework.util.manifestparser.ManifestParser.<init>(ManifestParser.java:181) ~[org.apache.felix.framework-5.6.12.jar:?]
               at org.apache.felix.framework.BundleRevisionImpl.<init>(BundleRevisionImpl.java:117) ~[org.apache.felix.framework-5.6.12.jar:?]
               at org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1282) ~[org.apache.felix.framework-5.6.12.jar:?]
               at org.apache.felix.framework.BundleImpl.revise(BundleImpl.java:1219) ~[org.apache.felix.framework-5.6.12.jar:?]
               at org.apache.felix.framework.Felix.updateBundle(Felix.java:2388) [org.apache.felix.framework-5.6.12.jar:?]
….

What this and the issue using 4.3.0 have is that I’m using BndTools 5.2.0 in both to generate my bundles.  This is the manifest of the bundle that failed.  Looks OK to me but perhaps there’s something subtle that shouldn’t be there?  All input appreciated.

Regards,
Scott

Manifest-Version: 1.0
Bnd-LastModified: 1607977206683
Bundle-ManifestVersion: 2
Bundle-Name: Medline BAM Model Schedule
Bundle-SymbolicName: medline.bam.schedule
Bundle-Version: 1.0.0.202012142020
Created-By: 14.0.2 (Oracle Corporation)
Export-Package: com.medline.bam.api;version="1.0.0";uses:="com.medline
.bam.api.metric,com.medline.bam.api.provider,com.medline.bam.api.repo
rt,com.medline.util.model.identifier,com.medline.util.query.jdbc,com.
medline.util.service,org.slf4j",com.medline.bam.api.metric;version="1
.0.0";uses:="com.medline.bam.api.provider",com.medline.bam.api.provid
er;version="1.0.0";uses:="com.medline.bam.api,com.medline.bam.api.met
ric,com.medline.bam.api.rule,com.medline.bam.api.schedule,com.medline
.util.query.api,com.medline.util.service,org.slf4j",com.medline.bam.a
pi.report;version="1.0.0";uses:="com.medline.bam.api,com.medline.util
.query.api,com.medline.util.query.http,com.medline.util.query.jdbc,co
m.medline.util.service",com.medline.bam.api.rule;version="1.0.0";uses
:="com.medline.bam.api,com.medline.bam.api.metric,com.medline.bam.api
.provider,com.medline.bam.api.schedule",com.medline.bam.api.schedule;
version="1.0.0";uses:="com.medline.util.model"
Git-Descriptor: 23996f2-dirty
Git-SHA: 23996f202ab9237416af1a4c35c209751d907c47
Import-Package: com.medline.bam.api;version="[1.0,2)",com.medline.bam.
api.metric;version="[1.0,2)",com.medline.bam.api.provider;version="[1
.0,2)",com.medline.bam.api.report;version="[1.0,2)",com.medline.bam.a
pi.rule;version="[1.0,2)",com.medline.bam.api.schedule;version="[1.0,
2)",com.medline.util,com.medline.util.model;version="[1.0,2)",com.med
line.util.model.identifier;version="[1.0,2)",com.medline.util.query.a
pi,com.medline.util.query.http,com.medline.util.query.jdbc,com.medlin
e.util.service,org.apache.commons.lang3;version="[3.4,4)",org.slf4j
Private-Package: com.medline.bam.schedule
Provide-Capability: osgi.service;objectClass:List<String>="com.medline
.bam.api.schedule.IScheduleFactory";uses:="com.medline.bam.api.schedu
le"
Require-Capability: osgi.extender;filter:="(&(osgi.extender=osgi.compo
nent)(version>=1.3.0)(!(version>=2.0.0)))",osgi.ee;filter:="(&(osgi.e
e=JavaSE)(version=1.8))"
Service-Component: OSGI-INF/com.medline.bam.schedule.ScheduleFactory.x
ml
Tool: Bnd-5.2.0.202010142003

From: Jean-Baptiste Onofre <jb...@nanthrax.net>
Sent: Thursday, December 03, 2020 9:52 AM
To: user@karaf.apache.org
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
Hi Scott,

I’m not able to reproduce your issue (neither on MacOS or Linux (Debian, Ubuntu), nor on Jenkins).

I tested with adatjdk and oracle jdk. I will download test with OpenJDK (it should be pretty close to Adapt).

Regards
JB


Le 3 déc. 2020 à 16:04, Leschke, Scott <SL...@medline.com>> a écrit :

Hi JB,
I’m curious if you have any info on the issue below. I tested using HotSpot and got the same result. As I’ve mentioned, I find this particularly perplexing as one of the packages that gets flagged is java.lang.
Is there anything you’d like me to try on my end regarding this?
Scott Leschke
From: Leschke, Scott <SL...@medline.com>>
Sent: Monday, November 16, 2020 7:54 AM
To: user@karaf.apache.org<ma...@karaf.apache.org>
Subject: RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
Yes, I apologize. I’m running openjdk 14.whatever and the OpenJ9 VM. Perhaps it’s J9. When I saw this issue previously, with 4.2.10 I believe, I think I was using openjdk 11 and J9.
Scott
From: Jean-Baptiste Onofre <jb...@nanthrax.net>>
Sent: Monday, November 16, 2020 1:13 AM
To: user@karaf.apache.org<ma...@karaf.apache.org>
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
________________________________
I just checked on java.specification.version is 14, so it’s fine.
I also checked with JDK 14.0.1 on Mac and it works fine (at least for Karaf examples).
I’m checking on Windows VM.
Regards
JB
Le 2 nov. 2020 à 01:48, Leschke, Scott <SL...@medline.com>> a écrit :
Karaf 4.3.0 on Windows, JDK 14. All java.* packages, including java.lang, show as Unsatisfied Requriements in bundle:diag output. Setting
karaf.framework=equinox
yields similar results.
org.osgi.framework.BundleException: Unable to resolve medline.bam.provider.jdbc [181](R 181.0): missing requirement [medline.bam.provider.jdbc [181](R 181.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0))) [caused by: Unable to resolve medline.osgi [169](R 169.0): missing requirement [medline.osgi [169](R 169.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.util.service)(version>=1.0.0)(!(version>=2.0.0))) [caused by: Unable to resolve medline.util [163](R 163.0): missing requirement [medline.util [163](R 163.0)] osgi.wiring.package; (osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!q6M6Du7f0xiSnnAzLzvUs3aLfck7r20ezWQc7Q_why5WXrRefvh1fiGcgNFV4xk$>)]] Unresolved requirements: [[medline.bam.provider.jdbc [181](R 181.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0)))]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) ~[?:?]
….
Scott

Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Scott,

I’m not able to reproduce your issue (neither on MacOS or Linux (Debian, Ubuntu), nor on Jenkins).

I tested with adatjdk and oracle jdk. I will download test with OpenJDK (it should be pretty close to Adapt).

Regards
JB

> Le 3 déc. 2020 à 16:04, Leschke, Scott <SL...@medline.com> a écrit :
> 
> Hi JB,
>  
> I’m curious if you have any info on the issue below.  I tested using HotSpot and got the same result.  As I’ve mentioned, I find this particularly perplexing as one of the packages that gets flagged is java.lang.
>  
> Is there anything you’d like me to try on my end regarding this?
>  
> Scott Leschke
>  
> From: Leschke, Scott <SLeschke@medline.com <ma...@medline.com>> 
> Sent: Monday, November 16, 2020 7:54 AM
> To: user@karaf.apache.org <ma...@karaf.apache.org>
> Subject: RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages
>  
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> Yes, I apologize. I’m running openjdk 14.whatever and the OpenJ9 VM.  Perhaps it’s J9.  When I saw this issue previously, with 4.2.10 I believe, I think I was using openjdk 11 and J9.
>  
> Scott
>  
> From: Jean-Baptiste Onofre <jb@nanthrax.net <ma...@nanthrax.net>> 
> Sent: Monday, November 16, 2020 1:13 AM
> To: user@karaf.apache.org <ma...@karaf.apache.org>
> Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages
>  
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> I just checked on java.specification.version is 14, so it’s fine.
>  
> I also checked with JDK 14.0.1 on Mac and it works fine (at least for Karaf examples).
>  
> I’m checking on Windows VM.
>  
> Regards
> JB
>  
> 
> Le 2 nov. 2020 à 01:48, Leschke, Scott <SLeschke@medline.com <ma...@medline.com>> a écrit :
>  
> Karaf 4.3.0 on Windows, JDK 14.   All java.* packages, including java.lang, show as Unsatisfied Requriements in bundle:diag output.  Setting
> karaf.framework=equinox
> yields similar results.
>  
> org.osgi.framework.BundleException: Unable to resolve medline.bam.provider.jdbc [181](R 181.0): missing requirement [medline.bam.provider.jdbc [181](R 181.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0))) [caused by: Unable to resolve medline.osgi [169](R 169.0): missing requirement [medline.osgi [169](R 169.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.util.service)(version>=1.0.0)(!(version>=2.0.0))) [caused by: Unable to resolve medline.util [163](R 163.0): missing requirement [medline.util [163](R 163.0)] osgi.wiring.package; (osgi.wiring.package=java.io <https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!q6M6Du7f0xiSnnAzLzvUs3aLfck7r20ezWQc7Q_why5WXrRefvh1fiGcgNFV4xk$>)]] Unresolved requirements: [[medline.bam.provider.jdbc [181](R 181.0)] osgi.wiring.package; (&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0)))]
>                at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
>                at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) ~[?:?]
> ….
>  
> Scott