Does this JBoss behaviour conform with JCA spec?

[roman_heinz]

Hi.

I have connector to a legacy Windows COM system, which uses bridge2java.dll as COM bridge.

All works fine on JBoss 3.2.1, if I place the dll outside the *.rar (e.g. in jre/bin)

But when I move the dll into the connector's *.rar, the native lib isn't reachable from my connector classes.
(UnsatisfiedLinkError)

As far as I understand the specs, the deployer (appserver) must load native libs in rar archives and make the accesible for the connector classes.

As in
http://java.sun.com/docs/books/jni/html/design.html#6908
, the native lib is associated with the classloader of the immediate caller of System.loadLibrary().

A patched SubDeployerSupprt.class reveals that this is:
org.jboss.mx.loading.UnifiedClassLoader3@c623af{ url=file:/C:/development/java/programs/jboss-3.2.1_tomcat-4.1.24/server/default/tmp/deploy/server/default/deploy/jboss-jca.sar/2.jboss-jca.sar ,addedOrder=4}
during jboss startup, which loads the native library from the RARDeployer.

The classloader of my connector class, that fails using native functions was:
org.jboss.mx.loading.UnifiedClassLoader3@1342545{ url=file:/C:/development/java/programs/jboss-3.2.1_tomcat-4.1.24/server/default/tmp/deploy/server/default/deploy/CPiSales.ear/39.CPiSales.ear ,addedOrder=23}
(That time, I tried EAR packaging)

I suppose, that these two classloaders are not related in a way, that makes delegation and correct access to the native lib possible.
What's wrong here?

[ ] Roman
[ ] JBoss
[ ] The specs

??!?!

regards,
Roman

[davidjencks]

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

[andygodwin]

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.

[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