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. 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] > > -- Cheers, Stuart
