You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Damian Minkov <da...@damencho.com> on 2007/11/09 08:14:55 UTC
classloader problem with native code
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: classloader problem with native code
Posted by Damian Minkov <da...@damencho.com>.
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 <he...@ungoverned.org> wrote:
> Stuart McCulloch wrote:
> > On 09/11/2007, Richard S. Hall <he...@ungoverned.org> 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 <ka...@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>>> On 11/9/07, Damian Minkov <da...@damencho.com> 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 <ka...@gmail.com> 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 <da...@damencho.com> 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: users-unsubscribe@felix.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> --
> >>>>>>>> Karl Pauls
> >>>>>>>> karlpauls@gmail.com
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>
> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> --
> >>>>>> Karl Pauls
> >>>>>> karlpauls@gmail.com
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >>
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: classloader problem with native code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stuart McCulloch wrote:
> On 09/11/2007, Richard S. Hall <he...@ungoverned.org> 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 <ka...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>> On 11/9/07, Damian Minkov <da...@damencho.com> 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 <ka...@gmail.com> 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 <da...@damencho.com> 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: users-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Karl Pauls
>>>>>>>> karlpauls@gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Karl Pauls
>>>>>> karlpauls@gmail.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: classloader problem with native code
Posted by Stuart McCulloch <st...@jayway.net>.
On 09/11/2007, Richard S. Hall <he...@ungoverned.org> 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 <ka...@gmail.com> wrote:
> >>>
> >>>> On 11/9/07, Damian Minkov <da...@damencho.com> 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 <ka...@gmail.com> 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 <da...@damencho.com> 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: users-unsubscribe@felix.apache.org
> >>>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> --
> >>>>>> Karl Pauls
> >>>>>> karlpauls@gmail.com
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>>
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>> --
> >>>> Karl Pauls
> >>>> karlpauls@gmail.com
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers, Stuart
Re: classloader problem with native code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
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.
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 <ka...@gmail.com> wrote:
>>>
>>>> On 11/9/07, Damian Minkov <da...@damencho.com> 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 <ka...@gmail.com> 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 <da...@damencho.com> 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: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Karl Pauls
>>>>>> karlpauls@gmail.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: classloader problem with native code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <ka...@gmail.com> wrote:
>>
>>> On 11/9/07, Damian Minkov <da...@damencho.com> 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 <ka...@gmail.com> 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 <da...@damencho.com> 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: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: classloader problem with native code
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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?
-> richard
> Thanks,
> damencho
>
> On 11/9/07, Karl Pauls <ka...@gmail.com> wrote:
>
>> On 11/9/07, Damian Minkov <da...@damencho.com> 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 <ka...@gmail.com> 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 <da...@damencho.com> 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: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: classloader problem with native code
Posted by Damian Minkov <da...@damencho.com>.
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.
Thanks,
damencho
On 11/9/07, Karl Pauls <ka...@gmail.com> wrote:
> On 11/9/07, Damian Minkov <da...@damencho.com> 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 <ka...@gmail.com> 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 <da...@damencho.com> 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: users-unsubscribe@felix.apache.org
> > > > For additional commands, e-mail: users-help@felix.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Karl Pauls
> > > karlpauls@gmail.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: classloader problem with native code
Posted by Karl Pauls <ka...@gmail.com>.
On 11/9/07, Damian Minkov <da...@damencho.com> 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 <ka...@gmail.com> 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 <da...@damencho.com> 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: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> >
> >
> > --
> > Karl Pauls
> > karlpauls@gmail.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: classloader problem with native code
Posted by Damian Minkov <da...@damencho.com>.
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.
should I remove the System.loadLibrary from the lib loading the native code ?
damencho
On 11/9/07, Karl Pauls <ka...@gmail.com> 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 <da...@damencho.com> 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: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: classloader problem with native code
Posted by Karl Pauls <ka...@gmail.com>.
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 <da...@damencho.com> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org