Excellent post, should turn it into a blog.
Kind regards,
Peter Kriens
On 29 apr 2011, at 13:39, Holger Hoffstätte wrote:
>
> Sorry for writing so much but you asked for it.. :-)
>
> On 28.04.2011 20:08, duncan wrote:
>> We are accessing native libraries from Java. This works outside
On 29.04.2011 17:21, Holger Hoffstätte wrote:
> Probably the biggest problem is the fact that the DT_RUNPATH is very
> limited in size. A truly dynamic & secure solution would be to rewrite
> the DT_RUNPATH ELF header from Java so that the path is short, but
> private (pid or short random token)..
Holger,
Thanks for the amazingly helpful response. We now have enough
information to get our app running.
At least this email thread will help other people understand what is
going on if they run into this issue.
Cheers
Duncan
2011/4/29 Holger Hoffstätte :
> On 29.04.2011 17:30, Richard
On 29.04.2011 17:30, Richard S. Hall wrote:
>> In that case the only way out is to first try $ORIGIN and, failing that,
>> a fixed location like /tmp or any other directory to which your bundle
>> can unpack the libraries and try again. It's much more difficult to get
>> right since you really want
On 4/29/11 11:21, Holger Hoffstätte wrote:
On 29.04.2011 16:31, Daniel Faber wrote:
wow, awesome post with great detailed explanations which I am very
interested in because we had a similar problem. I have just one
Thanks!
I've read chapter 3.9 "Loading Native Code Libraries" in the OSGi spe
On 29.04.2011 16:31, Daniel Faber wrote:
> wow, awesome post with great detailed explanations which I am very
> interested in because we had a similar problem. I have just one
Thanks!
> I've read chapter 3.9 "Loading Native Code Libraries" in the OSGi spec
> again and it seems the framework is n
On 4/29/11 10:31, Daniel Faber wrote:
Hey Holger,
wow, awesome post with great detailed explanations which I am very
interested in because we had a similar problem. I have just one
question and like to discuss a small feature request:
On 29.04.2011 13:39, Holger Hoffstätte wrote:
[first part
yeah, as i said, if you want to have a solution that doesn't depend on
specific framework behaviour all you can do is the approach i outlined
before (i.e., extract the libs yourself and a do a System.load()).
However, the "extract all libs on first request" was the default
behaviour of felix for a
Hey Holger,
wow, awesome post with great detailed explanations which I am very
interested in because we had a similar problem. I have just one
question and like to discuss a small feature request:
On 29.04.2011 13:39, Holger Hoffstätte wrote:
> [first part skipped, let's say we have changed our
Sorry for writing so much but you asked for it.. :-)
On 28.04.2011 20:08, duncan wrote:
> We are accessing native libraries from Java. This works outside of
> OSGi and in OSGi on Windows but not on Linux probably because the dll
> and so linking behave differently.
Yes and no. They work differen
I guess that in your case the only thing you can do is to extract the
libraries yourself i.e., on Bundle start-up you would extract all
libraries via BundleContext.getEntry() into a tmp dir that you create
via BundleContext.getDataFile() and then load your top-level dll via a
System.load() call dir
Hi Richard,
Thanks for the reply. When you said
> Yes, to ensure your native library dependencies are met in OSGi, it is best
> to explicitly load them in the proper order.
I think the crux of the problem is that for these particular libraries
there is no linear order that works.
You can t
On 4/28/11 16:56, duncan wrote:
Hi Angelo,
Thanks for your response. I understand what you wrote but I think I am
at the point where I have convinced myself that using
System.loadLibrary() within OSGi can be subtly different to using it
outside. The behavior might be equivalent if you have a sin
Hi Angelo,
Thanks for your response. I understand what you wrote but I think I am
at the point where I have convinced myself that using
System.loadLibrary() within OSGi can be subtly different to using it
outside. The behavior might be equivalent if you have a single library
but in my situation we
Hi Duncan,
Bundle-NativeCode will probably be your best bet: it allows you to leave the
selection of the library up to the framework, and you can quite easily reload
your library by updating the bundle.
You will have to load your libraries with System.loadLibrary, OSGi only takes
care of select
@felix.apache.org
Sent: Mon, September 27, 2010 9:46:52 AM
Subject: Re: Bundle-NativeCode question...
On 9/27/10 11:07, Tony Anecito wrote:
> First off thanks Richard for your prompt replies.
>
> What I did using web start was have seperate bundles for each OS/arch for the
> swing client so
m: Richard S. Hall
To: users@felix.apache.org
Sent: Sun, September 26, 2010 9:09:06 PM
Subject: Re: Bundle-NativeCode question...
On 9/26/10 22:22, Tony Anecito wrote:
Hi All,
I have my native libs for each OS in separate jars and in some cases I have
quite a few jars. I have some simple questi
-Tony
- Original Message
From: Richard S. Hall
To: users@felix.apache.org
Sent: Mon, September 27, 2010 7:45:04 AM
Subject: Re: Bundle-NativeCode question...
On 9/26/10 23:41, Tony Anecito wrote:
> Okay the reason I asked about the *.dll because I have over 200 dlls. I can
> writ
On 9/27/10 1:52, Marcel Offermans wrote:
On 27 Sep 2010, at 5:09 , Richard S. Hall wrote:
On 9/26/10 22:22, Tony Anecito wrote:
I have my native libs for each OS in separate jars and in some cases I have
quite a few jars. I have some simple questions
1. Can I keep my native jars as separate b
o: users@felix.apache.org
Sent: Sun, September 26, 2010 9:09:06 PM
Subject: Re: Bundle-NativeCode question...
On 9/26/10 22:22, Tony Anecito wrote:
Hi All,
I have my native libs for each OS in separate jars and in some cases I have
quite a few jars. I have some simple questions
1. Can I keep m
On 27 Sep 2010, at 5:09 , Richard S. Hall wrote:
> On 9/26/10 22:22, Tony Anecito wrote:
>> I have my native libs for each OS in separate jars and in some cases I have
>> quite a few jars. I have some simple questions
>>
>> 1. Can I keep my native jars as separate bundles?
>
> No, they must be pa
for a first time user of an app using OSGi/Felix will the jvm be loaded using
some attribute of a bundle?
Thanks,
-Tony
- Original Message
From: Richard S. Hall
To: users@felix.apache.org
Sent: Sun, September 26, 2010 9:09:06 PM
Subject: Re: Bundle-NativeCode question...
On 9/26
Can't remember the reference but osname=win7 will work. So will win32 actually
if they happen to use the same dlls.
- Joel
From: Tony Anecito [adanec...@yahoo.com]
Sent: Sunday, September 26, 2010 8:22 PM
To: Apache-felix-Dev
Subject: Bundle-NativeCode que
On 9/26/10 22:22, Tony Anecito wrote:
Hi All,
I have my native libs for each OS in separate jars and in some cases I have
quite a few jars. I have some simple questions
1. Can I keep my native jars as separate bundles?
No, they must be packaged in the bundle JAR containing the dependent
nat
24 matches
Mail list logo
