tag:blogger.com,1999:blog-6726488390498969778.post9098530656792284830..comments2023-05-11T12:17:38.341+02:00Comments on Robert Varttinen's blog: Bundle-NativeCode in the OSGi manifestR. Varttinenhttp://www.blogger.com/profile/09654450429903963673noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-6726488390498969778.post-20397717191290388082011-06-02T06:57:57.132+02:002011-06-02T06:57:57.132+02:00Hi,
Thank you for this wonderful article. It is ve...Hi,<br />Thank you for this wonderful article. It is very informative.<br /><br />I have a scenario where my Dll is depending on an external library. In such a case my bundle start fails saying cant find dependent libraries. Please let me know how to handle such dependencies.<br /><br />Thank you,<br />VinayVinayhttps://www.blogger.com/profile/04234194779948581684noreply@blogger.comtag:blogger.com,1999:blog-6726488390498969778.post-15281826188416055982010-03-01T18:48:11.944+01:002010-03-01T18:48:11.944+01:00:):)Unknownhttps://www.blogger.com/profile/00122786773676174452noreply@blogger.comtag:blogger.com,1999:blog-6726488390498969778.post-40868057335456761022008-12-05T15:07:00.000+01:002008-12-05T15:07:00.000+01:00Great comment Michael! Thank you! Yes, one has to ...Great comment Michael! Thank you! <BR/>Yes, one has to fiddle around with the LD_LIBRARY_PATH on Linux/Unix systems, PATH on Win32. And, yes it is a bit cumbersome at times (well, most of the time actually). <BR/>Some people I know use the technique you mention, calling System.loadLibrary(..) for each library needed in the process space. <BR/>There are some dependency walkers available to help in this respect. <BR/>Another way I've seen; statically link those libraries yo need, but that can make some libraries rather large. Nothing I'll recommend for anything but quite small things... <BR/><BR/>To sum up: doing stuff on the native side is often tricky, we are outside the Java sandbox and that has to be taken into consideration when doing these kind of things. It is "unsafe" in many respects ...R. Varttinenhttps://www.blogger.com/profile/09654450429903963673noreply@blogger.comtag:blogger.com,1999:blog-6726488390498969778.post-80236064170479988672008-12-05T01:28:00.000+01:002008-12-05T01:28:00.000+01:00Hi,indeed OSGi could really help to manage native ...Hi,<BR/>indeed OSGi could really help to manage native code in a better way (also with the update option).<BR/>Anyway it should me mentioned that you have to develop native code directly for OSGi.<BR/>For example if you would like to integrate legacy native code or third party code consisting of more than one DLL or SO file you will run into trouble.<BR/>The problem occurs if the native files have dependencies to each other. Generally a DLL finds its dependent DLLs by looking in the library path.<BR/>In OSGi you would have to load all DLLs or SO files manually by using System.loadLibrary(...). This means also that you have to find out the dependencies to all DLLs or SO files.<BR/>I run into heavy trouble under Linux because it seems that the JVM loads native libraries locally instead of globally which means that the manual loading mechanism with System.loadLibrary(...) does not work anymore.<BR/>The bundle update process causes much more problems then because the framework implementations rename the native libraries because the JVM does not offer a direct unload library command.<BR/><BR/>Fazit: OSGi offers a great possibility by managing native code as long as you're only working with JNI code which has no dependencies to other DLLs.<BR/>// michaelAnonymousnoreply@blogger.com