You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Frizz <fr...@googlemail.com> on 2014/03/19 06:02:56 UTC
Custom ClassLoader
I'd like to implement my own custom ClassLoader. Basically it should do
exactly what the default OSGi ClassLoader does.
I am using Karaf/Felix, so in my case that's
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader
The reason for implementing my own class loader is this: I use JNI to load
a DLL (with System.load()). But everytime I redeploy my bundle I get a
UnsatisfiedLinkError exception: Native Library xyz.dll already loaded in
another classloader.
This is, because the DLL is already loaded by the JVM - and stays as long
as the ClassLoader that loaded it is NOT garbage collected.
So I want to do something like this:
CustomClassLoader cl = new CustomClassLoader();
Class ca = cl.findClass("myPackage.MyClass");
Object a = ca.newInstance();
Method p = ca.getMethod("myMethod");
p.invoke(a);
p = null;
ca = null;
a = null;
cl = null;
System.gc();
Hopefully after that the CustomClassLoader is garbage collected - and the
DLL is unloaded from the container.
*What I found strange:* Even so each bundle has it's own ClassLoader, an
"osgi:uninstall <bundle>" does not unload the DLL - which means that the
bundles ClassLoader is still alive (and not garbage collected).
Re: javax.net.debug=ssl
Posted by Achim Nierbeck <bc...@googlemail.com>.
As far as I can tell from here,
these settings look ok.
Did you try to start Karaf with bin/karaf instead of the wrapper?
regards, Achim
2014-03-31 9:49 GMT+02:00 Laci Gaspar <la...@gmail.com>:
> this is what it looks like:
>
> wrapper.java.additional.1=-Dkaraf.home=%KARAF_HOME%
> wrapper.java.additional.2=-Dkaraf.base=%KARAF_BASE%
> wrapper.java.additional.3=-Dkaraf.data=%KARAF_DATA%
> wrapper.java.additional.4=-Dcom.sun.management.jmxremote
> wrapper.java.additional.5=-Dkaraf.startLocalConsole=false
> wrapper.java.additional.6=-Dkaraf.startRemoteShell=true
>
> wrapper.java.additional.7=-Djava.endorsed.dirs=%JAVA_HOME%/jre/lib/endorsed:%JAVA_HOME%/lib/endorsed:%KARAF_HOME%/lib/endorsed
>
> wrapper.java.additional.8=-Djava.ext.dirs=%JAVA_HOME%/jre/lib/ext:%JAVA_HOME%/lib/ext:%KARAF_HOME%/lib/ext
>
> wrapper.java.additional.9=-XX:PermSize=512m
> wrapper.java.additional.10=-XX:MaxPermSize=3000m
> wrapper.java.additional.11=-Djavax.net.debug=ssl
>
> best,
> Laci
>
>
> On 31.03.2014 09:46, Achim Nierbeck wrote:
>
> As I have no idea how the talend-runtime-wrapper.conf does look like,
> here some "generic" answers.
> Make sure you don't have a "gap" between your additional settings,
> make sure you don't overwrite your wrapper setting.
>
> regards, Achim
>
>
> 2014-03-31 9:36 GMT+02:00 Laci Gaspar <la...@gmail.com>:
>
>> Hi
>> Becaust I have some ssl issues I tried to set
>> wrapper.java.additional.11=-Djavax.net.debug=ssl
>> in talend-runtime-wrapper.conf but it has no effect. Any idea why this
>> doesn't work?
>>
>> best,
>> Laci
>>
>>
>
>
> --
>
> 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/>
>
> Software Architect / Project Manager / Scrum Master
>
>
>
--
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/>
Software Architect / Project Manager / Scrum Master
Re: javax.net.debug=ssl
Posted by Laci Gaspar <la...@gmail.com>.
this is what it looks like:
wrapper.java.additional.1=-Dkaraf.home=%KARAF_HOME%
wrapper.java.additional.2=-Dkaraf.base=%KARAF_BASE%
wrapper.java.additional.3=-Dkaraf.data=%KARAF_DATA%
wrapper.java.additional.4=-Dcom.sun.management.jmxremote
wrapper.java.additional.5=-Dkaraf.startLocalConsole=false
wrapper.java.additional.6=-Dkaraf.startRemoteShell=true
wrapper.java.additional.7=-Djava.endorsed.dirs=%JAVA_HOME%/jre/lib/endorsed:%JAVA_HOME%/lib/endorsed:%KARAF_HOME%/lib/endorsed
wrapper.java.additional.8=-Djava.ext.dirs=%JAVA_HOME%/jre/lib/ext:%JAVA_HOME%/lib/ext:%KARAF_HOME%/lib/ext
wrapper.java.additional.9=-XX:PermSize=512m
wrapper.java.additional.10=-XX:MaxPermSize=3000m
wrapper.java.additional.11=-Djavax.net.debug=ssl
best,
Laci
On 31.03.2014 09:46, Achim Nierbeck wrote:
> As I have no idea how the talend-runtime-wrapper.conf does look like,
> here some "generic" answers.
> Make sure you don't have a "gap" between your additional settings,
> make sure you don't overwrite your wrapper setting.
>
> regards, Achim
>
>
> 2014-03-31 9:36 GMT+02:00 Laci Gaspar <lacigas@gmail.com
> <ma...@gmail.com>>:
>
> Hi
> Becaust I have some ssl issues I tried to set
> wrapper.java.additional.11=-Djavax.net.debug=ssl
> in talend-runtime-wrapper.conf but it has no effect. Any idea why
> this doesn't work?
>
> best,
> Laci
>
>
>
>
> --
>
> 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/>
>
> Software Architect / Project Manager / Scrum Master
>
Re: javax.net.debug=ssl
Posted by Achim Nierbeck <bc...@googlemail.com>.
As I have no idea how the talend-runtime-wrapper.conf does look like,
here some "generic" answers.
Make sure you don't have a "gap" between your additional settings,
make sure you don't overwrite your wrapper setting.
regards, Achim
2014-03-31 9:36 GMT+02:00 Laci Gaspar <la...@gmail.com>:
> Hi
> Becaust I have some ssl issues I tried to set
> wrapper.java.additional.11=-Djavax.net.debug=ssl
> in talend-runtime-wrapper.conf but it has no effect. Any idea why this
> doesn't work?
>
> best,
> Laci
>
>
--
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/>
Software Architect / Project Manager / Scrum Master
javax.net.debug=ssl
Posted by Laci Gaspar <la...@gmail.com>.
Hi
Becaust I have some ssl issues I tried to set
wrapper.java.additional.11=-Djavax.net.debug=ssl
in talend-runtime-wrapper.conf but it has no effect. Any idea why this
doesn't work?
best,
Laci
Re: Custom ClassLoader
Posted by Frizz <fr...@googlemail.com>.
Hallo JB,
> Did you try with both Felix and Equinox ?
Only Felix.
My test bundle is pretty stand-alone: Start, load DLL, call one method from
DLL - that's it.
So I was wondering why "osgi:uninstall <bundle>" plus "osgi:install
<bundle>" did not work (still caused the UnsatisfiedLinkError / "Native
Library already
loaded in another classloader" exception).
If you are not in these conditions, the -XX:+CMSClassUnloadingEnabled JVM
> arguments may help as well.
>
It seems this is no longer available in Java 1.7.
cheers,
Frizz
Re: Custom ClassLoader
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
Did you try with both Felix and Equinox ?
Generally speaking, OSGi provides an API to “unload” a bundle. This is
possible because each OSGi bundle has its own classloader.
However bundles that import packages from an unloaded bundle still have
references to the bundle’s classloader and therefore to the bundle
classes. In addition, all classes which inherit from or have members
with types from the the referenced bundle have indirect references to
the original bundle classloader. The original classloader for the
unloaded bundle therefore cannot yet be garbage-collected (nor any class
the classloader ever loaded). If an unloaded bundle is replaced by
another which provides the same packages (eg has been upgraded to a new
version) then class-cast-exceptions can also occur when communicating
between bundles that have bound to different (old vs new) versions of
those packages; in addition, bundles resolved against the old
uninstalled bundle version will still be using old/obsolete code.
OSGi therefore supports refreshing a bundle, forcing OSGi to re-resolve
its imported packages, and if any change has occurred in the providing
classloaders then the refreshed bundle’s classloader is discarded (ie as
if the refreshed bundle had itself been unloaded/reloaded). Bundles that
then use exports from the refreshed bundle should also be refreshed.
This cascading refresh process doesn’t work well if any bundle is using
static variables, as their value is lost when the bundle is refreshed.
And if a static variable in a non-refreshed bundle references a class
from another bundle then that blocks garbage-collection of that bundle’s
classloader including all classes it has previously loaded.
If you are not in these conditions, the -XX:+CMSClassUnloadingEnabled
JVM arguments may help as well.
I hope it helps.
Regards
JB
On 03/19/2014 06:02 AM, Frizz wrote:
> I'd like to implement my own custom ClassLoader. Basically it should do
> exactly what the default OSGi ClassLoader does.
>
> I am using Karaf/Felix, so in my case that's
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader
>
> The reason for implementing my own class loader is this: I use JNI to
> load a DLL (with System.load()). But everytime I redeploy my bundle I
> get a UnsatisfiedLinkError exception: Native Library xyz.dll already
> loaded in another classloader.
>
> This is, because the DLL is already loaded by the JVM - and stays as
> long as the ClassLoader that loaded it is NOT garbage collected.
>
> So I want to do something like this:
>
> CustomClassLoader cl = new CustomClassLoader();
> Class ca = cl.findClass("myPackage.MyClass");
> Object a = ca.newInstance();
> Method p = ca.getMethod("myMethod");
> p.invoke(a);
> p = null;
> ca = null;
> a = null;
> cl = null;
> System.gc();
>
> Hopefully after that the CustomClassLoader is garbage collected - and
> the DLL is unloaded from the container.
>
> *What I found strange:* Even so each bundle has it's own ClassLoader, an
> "osgi:uninstall <bundle>" does not unload the DLL - which means that the
> bundles ClassLoader is still alive (and not garbage collected).
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com