-
1. Re: Does this JBoss behaviour conform with JCA spec?
davidjencks May 16, 2003 8:58 PM (in response to roman_heinz)Most likely jboss is the problem here. I haven't found a native library I can experiment with to try to load anything, and since I don't have windows your dll won't help me.
I just looked at the docs you pointed out and they suggest one cause of UnsatisfiedLinkError is trying to load the library twice. Can you provide the stack trace and any other info you might have? Is your adapter trying to load the dll? If so the deployer wiill load it, then your code will try to, getting the exception.
thanks
david jencks -
2. Re: Does this JBoss behaviour conform with JCA spec?
andygodwin May 17, 2003 2:44 PM (in response to roman_heinz)I've been looking at a similar problem recently,
only with an MBean SAR, not a RAR.
I found that if I print out the ClassLoader
parentage in both SubDeployerSupport and in the
MBean class that contains the native methods,
the SARDeployer ClassLoader instance is the
immediate parent of the MBean class ClassLoader
instance.
For normal java classes this is fine, because of the
normal parent delegation ... but it's not totally clear
to me that this applies to native libraries ... you'd
think so, perhaps, but it's not explicitly stated in the
JNI docs at Sun.
I think I can see a fix, I just haven't got round to
trying it out yet. -
3. Re: Does this JBoss behaviour conform with JCA spec?
roman_heinz May 19, 2003 2:14 AM (in response to roman_heinz)> I just looked at the docs you pointed out and they
> suggest one cause of UnsatisfiedLinkError is trying
> to load the library twice.
No, not in my case. AFAIK the specs, loading a library twice should be gently ignored.
> [...] Is your
> adapter trying to load the dll? If so the deployer
> wiill load it, then your code will try to, getting
> the exception.
No, my adaptor has no chance to load the library because when I use System.loadLibrary("bridge2java"),
the ClassLoader modifies this depending on the current OS and tries to load bridge2java.dll from a reachable path, e.g. jre/bin (but the dll is in my *.rar).
The RARDeployer unpacks the *.rar and is the only one, who knows the physical path to the unpacked dll (e.g. 'server/default/tmp/native/bridge2java.dll').
Therefore, RARDeployer is the only one who can (and actually does) load the dll via System.load("absolute_filename_with_suffix")
regards,
Roman