Hi Tim and also JB, of course most should be available from the jre props, but there is still the possibility to use a system fragment bundle. To me it looks a lot like this is what fits Tim most, as he needs to "patch" already existing containers. For this you need to create a specialized fragment bundle which contains something similar for the missing packages:
Fragment-Host: system.bundle; extension:=framework Export-Package: my.needed.package with the fragment host being system.bundle and the extension being framework the resolver knows to extend the system bundle. regards, Achim 2016-08-20 7:22 GMT+02:00 Jean-Baptiste Onofré <[email protected]>: > Hi Tim, > > IMHO, if those packages are available in all JVM (Oracle and IBM), we > should add in the Karaf default etc/jre.properties. > > Karaf 4 won't help if etc/jre.properties if not up to date. > > WDYT ? > > Regards > JB > > > On 08/19/2016 11:51 PM, thully wrote: > >> Hi, >> >> Our application (Cytoscape) uses Karaf as its OSGi container/shell - Karaf >> 3.0.3, to be specific. With our application, external developers can >> provide >> their own bundles ("apps") for use with the Cytoscape core framework. >> Lately, many of our app developers have run into problems relating to >> packages/bundles that are included in the JVM or with Karaf/Felix, but are >> not exported by the default configuration. >> >> One example of this is that some wanted to use JavaFX web functionality >> that >> required the netscape.javascript package, which is included in Java but >> not >> exported by the default Karaf configuration. Another example involves >> Xerces >> - some external app developers have tried to use Jena (which uses Xerces) >> but have had problems because Karaf includes some but not all Xerces >> packages in the bootdelegation (it seems KARAF-3596 references this issue, >> but has yet to be addressed in Karaf 3.x). >> >> Currently, what we have been doing is modifying the Karaf configuration to >> add missing packages to packages.extra or bootdelegation. While this >> resolves the problem, it doesn't help until we can cut a new release of >> Cytoscape, and it doesn't help those still on old Cytoscape versions >> unless >> they manually update their Karaf configuration files. >> >> Is there anything that can be done at the bundle level to work around this >> (i.e. to import classes included in Java or the Karaf framework but not >> exported by default, or to use one's own version of these classes instead >> of >> the not-exported version included with Karaf)? If not, would moving to >> Karaf >> 4 help in this regard, or is there a configuration change that would >> resolve >> all these cases? >> >> Tim Hull >> >> >> >> -- >> View this message in context: http://karaf.922171.n3.nabble. >> com/Application-using-Karaf-problems-with-packages-not-being >> -exported-by-default-configuration-tp4047592.html >> Sent from the Karaf - User mailing list archive at Nabble.com. >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master
