Hi all, I want just to report that the problem is fixed. The fix is as Richard wrote in previous mail - pre-loading the class that was causing the problem.
Thanks for the cooperation, damencho On 11/9/07, Richard S. Hall <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
