Stuart McCulloch wrote:
On 09/11/2007, Richard S. Hall <[EMAIL PROTECTED]> wrote:
After looking more closely at the wording of the problem, I notice that
you said that the native code is instantiating the class. If this is
actually the case, then you will need to check to see which class loader
the native code is using to do this...I am not familiar with how to
instantiate classes from native code.
you'd normally use:
jclass FindClass(JNIEnv *env, const char *name);
to load a class from native code - note that there's no option to pass in a
classloader.
The JVM will attempt to use the classloader of the _calling_ Java code (ie.
the loader of
the class who made the native call). If the native code wasn't invoked from
Java (ie. it's
from an attached native thread) then the JVM will use the system
classloader.
alternatively, some people will use:
jclass DefineClass(JNIEnv *env, jobject loader, const jbyte *buf, jsize
bufLen);
to load a class from a data stream, and here you can provide the classloader
to use.
It turns out after looking at the native code on Source Forge that they
are calling FindClass() on a thread not associated with a native method,
so it is using the system class loader. So this is problematic. They are
aware of this issue, though, and in some parts of their code they
pre-load classes to avoid this issue. So perhaps they could just
pre-load the class that Damian is having difficulty with too to make the
issue go away.
-> richard
Regardless, all native libs are associated with exactly one class
loader. So, the native code should try to get its associated class
loader, not the global app class loader, then everything should be ok I
would guess.
if the native call originates from Java code then yes, it should be just a
matter of
ensuring the same classloader is used for the relevant packages, which
should
be just a matter of using the right imports/exports.
however, if (somehow) the native call doesn't have a Java frame somewhere in
the stack then the system classloader will be used... so you'd probably need
to
also get the Java package(s) from the system classloader :(
Keep up posted.
-> richard
Richard S. Hall wrote:
Richard S. Hall wrote:
Damian Minkov wrote:
Hi,
here is the situation.
In sip-communicator there is a bundle named media service which
handles all the media stuff.
I'm trying to integrate some part of fmj project. So I have included
the needed libs
(fmj-sc.jar and lti-civil-no_s_w_t.jar) and I have included in the
bundle jar the needed civil.dll cause I'm currently testing on
windows.
Here is the manifest file I use.
Bundle-Activator: net.java.sip.communicator.impl.media.MediaActivator
Bundle-Name: Media Service Implementation
Bundle-Description: A bundle that offers Media capture and
presentation capabilities.
Bundle-Vendor: sip-communicator.org
Bundle-Version: 0.0.1
Bundle-NativeCode: /civil.dll; osname=WindowsXP; processor=x86;
Import-Package: org.osgi.framework,
net.java.sip.communicator.service.configuration,
net.java.sip.communicator.service.configuration.event,
net.java.sip.communicator.service.protocol,
net.java.sip.communicator.service.protocol.event,
net.java.sip.communicator.util,
net.java.sip.communicator.service.netaddr,
javax.swing,
javax.swing.event,
net.java.sip.communicator.service.fileaccess,
javax.sound,
javax.sound.sampled
Export-Package: net.java.sip.communicator.service.media,
net.java.sip.communicator.service.media.event,
net.java.sip.communicator.impl.media,
net.java.sip.communicator.impl.media.configuration
Is it a problem if the required dll is also in the path of the running
application.
I am confused from the above information. Are you including the fmj
JARs on the bundle's class path manifest header?
Talking with Damian in chat, I guess I didn't realize he was exploding
the JAR files into his bundle. I thought he was just embedding that
JAR files.
-> richard
-> richard
Thanks,
damencho
On 11/9/07, Karl Pauls <[EMAIL PROTECTED]> wrote:
On 11/9/07, Damian Minkov <[EMAIL PROTECTED]> wrote:
Hi,
I've done this but the problem stays.
The results are the same no matter whether I remove the libs from
global classpath or not.
But did you add a Bundle-NativeCode header to your manifest? Could
you
maybe share the manifest with us (and or some more information)?
should I remove the System.loadLibrary from the lib loading the
native code ?
no, you still need to do that.
regards,
Karl
damencho
On 11/9/07, Karl Pauls <[EMAIL PROTECTED]> wrote:
Hi Damian,
I think your last suggestion is the solution. Try to add a
Bundle-NativeCode header to your bundles manifest then the native
lib
should be loaded by your bundles classloader.
Let us know whether that fixes your problem.
regards,
Karl
On 11/9/07, Damian Minkov <[EMAIL PROTECTED]> wrote:
Hi,
I'm working on moving sip-communicator to FMJ. The FMJ lib uses
native
code for working with media devices.
The lib loads itself the native libs. But here is the problem.
There is
an object (VideoFormat) which is instantiated
in the native code and if I compare it ( instanceof ) in the
java code
with the class VideoFormat the result is FALSE.
Then I printed both classloaders :
- for the class loaded from java code result is -
org.apache.felix.framework.searchpolicy.ContentClassLoader
- and for the one that comes from native code it is -
sun.misc.Launcher$AppClassLoader
Then I noticed that the lib containing the VideoFormat class is
not only
in the bundle but and in the global classpath of the
running application. So I remove it from there and the native
code began
to fail as it cannot find the needed class.
Any ideas ? I have no special native code declarations in the
manifest
file of the bundle. If I have does Bundle-NativeCode declaration
will it change the classloader with the felix one for loading
classes
from native code ?
Thanks,
damencho
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Karl Pauls
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Karl Pauls
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
