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 <slesc...@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 <j...@nanthrax.net <mailto:j...@nanthrax.net>> > Sent: Thursday, December 03, 2020 9:52 AM > To: user@karaf.apache.org <mailto: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 <slesc...@medline.com > <mailto:slesc...@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 <slesc...@medline.com <mailto:slesc...@medline.com>> > Sent: Monday, November 16, 2020 7:54 AM > To: user@karaf.apache.org <mailto: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 <j...@nanthrax.net <mailto:j...@nanthrax.net>> > Sent: Monday, November 16, 2020 1:13 AM > To: user@karaf.apache.org <mailto: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. > 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 <slesc...@medline.com > <mailto:slesc...@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
