You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by thully <tm...@eng.ucsd.edu> on 2016/08/19 21:51:59 UTC
Application using Karaf - problems with packages not being exported
by default configuration
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.
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by thully <tm...@eng.ucsd.edu>.
I created a few issues relating to this: KARAF-4689 for the custom.properties
option for additional packages, and KARAF-4688 for adding
netscape.javascript to the JRE 1.8+ exports. Also, KARAF-3596 was opened
previously (by someone else) regarding only part of Xerces being exposed in
bootdelegation - it seems some patches were proposed but hasn't seen a
response in over a year.
For now, I think we'll just copy the config.properties entries to
custom.properties...
--
View this message in context: http://karaf.922171.n3.nabble.com/Application-using-Karaf-problems-with-packages-not-being-exported-by-default-configuration-tp4047592p4047795.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by Guillaume Nodet <gn...@apache.org>.
Yeah, maybe the properties in etc/config.properties should include an
additional property that would be taken from etc/custom.properties so that
it would be much easier to add stuff.
Please raise a JIRA if you think that would suit your needs.
2016-08-31 0:48 GMT+02:00 thully <tm...@eng.ucsd.edu>:
> I figured out why that was happening - it turns out we had packages listed
> in
> org.osgi.framework.system.packages.extra in custom.properties that were
> overriding the defaults in config.properties. As such, Xerces was never
> being exported, and org.apache.xerces.util isn't in boot delegation so we
> can't get access to it that way. Once I moved the custom additions to
> org.osgi.framework.system.packages.extra from custom.properties to
> config.properties, the bundle worked.
>
> With that said, what would be the best practice as far as adding system
> packages to a custom Karaf distribution and preserving the defaults? It
> seems someone added these to our custom.properties a long time ago, and I
> suspect they didn't realize it would prevent the defaults from being
> exported (we can into the same issue with sun.* packages and bootdelegation
> a while back).
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Application-using-Karaf-problems-with-packages-not-
> being-exported-by-default-configuration-tp4047592p4047767.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by thully <tm...@eng.ucsd.edu>.
I figured out why that was happening - it turns out we had packages listed in
org.osgi.framework.system.packages.extra in custom.properties that were
overriding the defaults in config.properties. As such, Xerces was never
being exported, and org.apache.xerces.util isn't in boot delegation so we
can't get access to it that way. Once I moved the custom additions to
org.osgi.framework.system.packages.extra from custom.properties to
config.properties, the bundle worked.
With that said, what would be the best practice as far as adding system
packages to a custom Karaf distribution and preserving the defaults? It
seems someone added these to our custom.properties a long time ago, and I
suspect they didn't realize it would prevent the defaults from being
exported (we can into the same issue with sun.* packages and bootdelegation
a while back).
--
View this message in context: http://karaf.922171.n3.nabble.com/Application-using-Karaf-problems-with-packages-not-being-exported-by-default-configuration-tp4047592p4047767.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by thully <tm...@eng.ucsd.edu>.
Also, one of our app developers has posted their attempt to make a bundle
that depends on taverna-robundle, while excluding Xerces from the embedded
dependencies and importing it from the system packages.
However, this does not work - the following exception occurs when Jena tries
to use a Xerces class:
java.lang.NoClassDefFoundError: org/apache/xerces/util/XMLChar
at org.apache.jena.rdf.model.impl.Util.notNameChar(Util.java:119)
at org.apache.jena.rdf.model.impl.Util.splitNamespaceXML(Util.java:77)
at org.apache.jena.graph.Node_URI.getLocalName(Node_URI.java:80)
It seems like this should work, as org.apache.xerces.util is in
org.osgi.system.packages.extra, and is imported using Import-Package in the
bundle manifest.
The source code is at:
https://github.com/matthiaskoenig/cy3robundle
--
View this message in context: http://karaf.922171.n3.nabble.com/Application-using-Karaf-problems-with-packages-not-being-exported-by-default-configuration-tp4047592p4047722.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by thully <tm...@eng.ucsd.edu>.
What we're looking for is a way that a bundle can function while embedding
bundles that require Xerces *without* making any changes to the assembly. As
an example, here is the first few lines of the stack trace we get from a
bundle trying to use a embedded dependency that requires Xerces.
java.lang.VerifyError: (class:
org/apache/xerces/impl/dv/xs/AbstractDateTimeDV, method: <clinit> signature:
()V) Bad type in putfield/putstatic
at org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl.<clinit>(Unknown Source)
at
org.apache.xerces.impl.dv.xs.SchemaDVFactoryImpl.createBuiltInTypes(Unknown
Source)
at org.apache.xerces.impl.dv.xs.SchemaDVFactoryImpl.<clinit>(Unknown
Source)
The dependency in question is taverna-robundle, which requires Jena (which
in term uses Xerces). We are setting transitive to true in the
maven-bundle-plugin configuration so that all of this is embedded in a
single bundle.
Any ideas?
--
View this message in context: http://karaf.922171.n3.nabble.com/Application-using-Karaf-problems-with-packages-not-being-exported-by-default-configuration-tp4047592p4047721.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by Guillaume Nodet <gn...@apache.org>.
Embedding dependencies such as Xerces may be a bit difficult, depending on
how you use it.
For example if you use the standard xml api, the api will most certainly
use the parser from the JVM. In order to use your own copy of xerces, you
need to create your factories explicitly i think.
On a more general note, one thing that might be doable, would be to
"generate" the packages.extra or boot delegation package list at startup
time. We do that offline during the build of the assembly based on the
jars included in the lib folder, but we could add an option to do that
during startup.
A slightly different way would be to better support the notion of library
when installing features, and not only while building assemblies. Those
libraries are used to add such providers (xerces, xalan, etc...) to the
endorsed folders, but you can't really add them at runtime.
2016-08-26 6:52 GMT+02:00 thully <tm...@eng.ucsd.edu>:
> Our users are just using maven-bundle-plugin. Whenever they've tried
> depending directly on projects that depend Xerces and use
> Embed-Dependencies
> as they would for any other dependency they want to embed, the resulting
> bundle does not load properly. What do they need to do differently due to
> Xerces being included in the Karaf distribution?
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Application-using-Karaf-problems-with-packages-not-
> being-exported-by-default-configuration-tp4047592p4047690.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by thully <tm...@eng.ucsd.edu>.
Our users are just using maven-bundle-plugin. Whenever they've tried
depending directly on projects that depend Xerces and use Embed-Dependencies
as they would for any other dependency they want to embed, the resulting
bundle does not load properly. What do they need to do differently due to
Xerces being included in the Karaf distribution?
--
View this message in context: http://karaf.922171.n3.nabble.com/Application-using-Karaf-problems-with-packages-not-being-exported-by-default-configuration-tp4047592p4047690.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by Achim Nierbeck <bc...@googlemail.com>.
Well one of the things you need to make sure is, how do the package version
look like, if the framework exported versions are set to 0.0.0 that might
interfere with versions correctly configured.
regarding embedded dependencies, yes this is possible, take a look at the
bnd documentation about how to configure this.
In that case also make sure you don't have those packages imported via
import-package that will interfere again.
regards, Achim
2016-08-22 20:11 GMT+02:00 thully <tm...@eng.ucsd.edu>:
> In the case of Xerces, app developers have been having problems using
> dependencies (most notably Jena) that depend on it, even if they provide
> their own version. Is there something special they need to do to tell
> OSGi/Karaf to use their private version of Xerces instead of using the
> bundled version?
>
> Also, is it possible to embed an extension bundle in a JAR using
> Embed-Dependencies in maven-bundle-plugin? In the case of
> netscape.javascript (or other missing system packages), this would make
> things a bit easier (as typically apps are distributed as single JARs).
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Application-using-Karaf-problems-with-packages-not-
> being-exported-by-default-configuration-tp4047592p4047621.html
> Sent from the Karaf - User mailing list archive at Nabble.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
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by thully <tm...@eng.ucsd.edu>.
In the case of Xerces, app developers have been having problems using
dependencies (most notably Jena) that depend on it, even if they provide
their own version. Is there something special they need to do to tell
OSGi/Karaf to use their private version of Xerces instead of using the
bundled version?
Also, is it possible to embed an extension bundle in a JAR using
Embed-Dependencies in maven-bundle-plugin? In the case of
netscape.javascript (or other missing system packages), this would make
things a bit easier (as typically apps are distributed as single JARs).
--
View this message in context: http://karaf.922171.n3.nabble.com/Application-using-Karaf-problems-with-packages-not-being-exported-by-default-configuration-tp4047592p4047621.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by Achim Nierbeck <bc...@googlemail.com>.
Of course, using those in private is always an option, and usually a better
one.
Never the less if it's supposed to be a "framework" package the framework
can be made aware of that fact via a system-fragment ;)
Regards, Achim
2016-08-20 7:54 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Another way is also to ship the packages in the bundles as private.
>
> It creates "big" bundles but convenient to provide atomic artifacts.
>
> My €0.01 ;)
>
> Regards
> JB
>
> On 08/20/2016 07:51 AM, Achim Nierbeck wrote:
>
>> 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é <jb@nanthrax.net
>> <ma...@nanthrax.net>>:
>>
>>
>> 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-pr
>> oblems-with-packages-not-being-exported-by-default-configura
>> tion-tp4047592.html
>> <http://karaf.922171.n3.nabble.com/Application-using-Karaf-
>> problems-with-packages-not-being-exported-by-default-conf
>> iguration-tp4047592.html>
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> 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
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> 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
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Another way is also to ship the packages in the bundles as private.
It creates "big" bundles but convenient to provide atomic artifacts.
My \u20ac0.01 ;)
Regards
JB
On 08/20/2016 07:51 AM, Achim Nierbeck wrote:
> 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� <jb@nanthrax.net
> <ma...@nanthrax.net>>:
>
> 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
> <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�
> jbonofre@apache.org <ma...@apache.org>
> 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
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by Achim Nierbeck <bc...@googlemail.com>.
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é <jb...@nanthrax.net>:
> 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é
> jbonofre@apache.org
> 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
Re: Application using Karaf - problems with packages not being
exported by default configuration
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com