[jira] Commented: (FELIX-1971) Native library name case sensitivity

["Richard S. Hall (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830279#action_12830279 ] 

Richard S. Hall commented on FELIX-1971:
----------------------------------------

I am not sure there is a good solution here, since the restriction would have to be on the entire path of the library. Additionally, Macs may or may not be case sensitive and different file systems allow you to choose. So, there is no general purpose solution.

Could this be as simple as having the framework log a WARNING with the passed in library name in the log message when the library isn't found? At least then you'd know what the request looked like.

> Native library name case sensitivity
> ------------------------------------
>
>                 Key: FELIX-1971
>                 URL: https://issues.apache.org/jira/browse/FELIX-1971
>             Project: Felix
>          Issue Type: Improvement
>          Components: Framework
>            Reporter: Rob Walker
>
> This one is something of a nasty - and I have to confess, I'm at a bit of a loss to see what the correct handling should be to ensure platform neutrality.
> We're starting to use a commercial lib - Java2Com from Neva object technologies (http://www.nevaobject.com/). This comes as a JAR with no source code - so you can't see the actual loadLibrary call. Luckily they have an active support forum which helped with this.
> The library is Windows only, and is called "corojdk11.dll". And in standalone code everything worked fine - soon as we bundled it, bang! No joy.
> The Manifest looked fine - pretty much same as we use for other DLLs
> Bundle-NativeCode: /corojdk11.dll; osname=WinNT; osname=Win2000; osname=Win2003; osname=WinXP; osname=WinVista; osname=Win7; osname=Win32; processor=x86; processor=x86-64
> And Felix was finding and unpacking the DLL fine on a Windows platfom. But we kept getting UnsatisfiedLink exception.
> Then the Neva guys sent us the loadLibrary line:
> System.loadLibrary("COROJDK11")
> You see the problem.
> Windows file names are not case sensitive - so this will load "corojdk11" fine also. BUT - JAR file names are case sensitive, so this fails to find the "corojdk11" within the bundle. The workaround for us is simple - bundle with upper case name:
> Bundle-NativeCode: /COROJDK11.dll; osname=WinNT; osname=Win2000; osname=Win2003; osname=WinXP; osname=WinVista; osname=Win7; osname=Win32; processor=x86; processor=x86-64
> But this seems something of a kludge.
> The issue I can see here is: 
> * Most platform have case sensitive names
> * JAR names are case sensitive
> So how do you handle the Windows scenario - the actual DLL could have any mix of case, so you can't really go searching the JAR for every case combination.
> Seems to me that an OSGi spec standardisation is needed e.g. "all Windows DLLs should be bundled in upper case" (or lower, whichever is preferred). Then when a loadLibrary for Windows comes in the framework knows to shift the case before the search and that if the spec is followed, the lib will be found.
> Of course - this clause may exist in the 4.2 spec already - and it could just be me that is out of date here!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.