Title: Message
I wouldn't think the DLL calling another DLL would be an issue. And even if there's a problem loading the second DLL, I wouldn't expect a Java-based exception to be the result.
 
In light of your classloader revelation, I'm afraid I'm stumped. JBoss does some funky stuff with classloaders which it sounds like might be causing you problems.
 
I'm all out of ideas. Sorry.
 
--
Danny Yates
 
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Kramer
Sent: 01 July 2004 13:59
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-user] unsatisfiedLinkError / jboss mbean unable to cal l native method in c++ .dll through JNI

Thanks for your response.   I do indeed have the static initializer block wrapping the call to loadLibrary() in my class that has native method.  Perhaps one piece of additional usefull info would be the .dll i'm calling actually calls another .dll.  
 
You mentioned this process actually does work.  Do you have a working example or can you offer any other insight into what may be causing the problem I have indicated?  It almost seems JBOSS is internally doing something after the libraries are loaded.  
 
Thanks
 
 
 
 
 
-----Original Message-----
From: Yates, Danny [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 01, 2004 4:20 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-user] unsatisfiedLinkError / jboss mbean unable to cal l native method in c++ .dll through JNI

OK. I wasn't aware of that bit of dodgy code. My apologies.
 
Windows still won't let you load a DLL more than once, but it seems the JVM maintains a separate cache of native method -> DLL function pointers on a per classloader basis.
 
In this case, you need to make sure that your System.loadLibrary() and your native calls are done from classes loaded by the same classloader. The easiest way to do this is, I guess, to have a static initialiser block make a System.loadLibrary() call in each class that has native methods (and this is the recommended practice anyway).
 
I'm not sure on how JBoss's classloader architecture would affect this - especially as you're using MBeans if I recall correctly.
 
If this still doesn't work, I would suggest externalising the JNI stuff into, say, an RMI based server. Then you can have a bunch of session beans which offer a facade to the RMI server, and you become platform neutral again.
 
Rgds,
 
Dan.
 
--
Danny Yates
 
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Kramer
Sent: 30 June 2004 15:23
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-user] unsatisfiedLinkError / jboss mbean unable to cal l native method i n c++ .dll through JNI

 
 
I explained that I looked in the .dll and updated my native function name from "aaBond_crv1_java" to "aaBond_crv1", to match what was in the .dll.  this did not work & I set it back, which does not work either in my jboss mbean, but works fine in a standalone app.  I also explained in detail how I generated that full method name with javah - jni, but that's getting away from the issue.  Let's not do that.
 
Once again,  I have a standalone app that works.  It works, so we have proven  .dll and calling class have matching method names.  Migrating this EXACT code to a class in a jboss mbean, and the .dll to the jboss/bin, I get the unsatisfiedLinkError on method call.  As mentioned, the loadLibrary(myDll) does not throw exception when wrapped in try-catch.
 
It is not obvious what i'm doing wrong here.  If you can offer anything, please advise.
 
thanks

 -----Original Message-----
From: Yates, Danny [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 30, 2004 9:59 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-user] unsatisfiedLinkError / jboss mbean unable to cal l native method i n c++ .dll through JNI

You cannot load more than one instance of a DLL into a given process. And System.loadLibrary() is specifically documented to only try and load one instance if called more than once.
 
Like I said, when the JVM reaches a method declared as 'native' in Java, it applies a simple set of rules to the package, class and method names to arrive at a function name which it expects to be exported from the DLL. The C function name and the Java method name that you gave on the forums simply don't match.
 
--
Danny Yates
 
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Kramer
Sent: 30 June 2004 15:00
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-user] unsatisfiedLinkError / jboss mbean unable to cal l native method i n c++ .dll through JNI

I appreciate your response, but there is still a gap here.  I am using windows, and I've seen in some other posts how unsatisfiedLinkError actually indicates more then one instance of the .dll has been loaded.  Do you have any experience or ideas about this?
 
 
I have tried System.loadLibrary("CJavaWrap"), with the .dll in the jboss/bin.   I'm glad to hear it should work, but I cannot see what we are doing wrong?!
 
-----Original Message-----
From: Yates, Danny [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 30, 2004 9:41 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-user] unsatisfiedLinkError / jboss mbean unable to cal l native method i n c++ .dll through JNI

Jeff,
 
As we discussed on the forum, there is really no magic to this. It works. If it doesn't there's something up with your config.
 
Other things that spring to mind:
 
1) System.loadLibrary() is defined to work in an implementation specific manner. In Windows, I think it delegates to the LoadLibrary API call. This looks in the path by default.
2) You don't need to .DLL extension. This is added by the JVM when running on Windows. (When running on Unix, it adds .so)
 
So, try just doing System.loadLibrary("myDLL") and make sure that the DLL is on the PATH, or in the current directory. This is more portable than using System.load()
 
However, I think the library is loading OK. If you check the Javadoc for UnsatisfiedLinkError, you'll see why it's thrown. And this corresponds with the reasons I gave you on the forum.
 
I repeat: THERE IS NOTHING IN JBOSS WHICH IS STOPPING THIS WORKING. You really need to write your own standalone Java program to get this working as a starting point. Don't rely on someone else's code. Don't rely on something from a vendor. Write your own 10 liner so that you fully understand and control the execution environment (PATH, environment and system properties, etc.)
 
Dan.
 
--
Danny Yates
 
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Kramer
Sent: 30 June 2004 14:10
To: '[EMAIL PROTECTED]'
Subject: [JBoss-user] unsatisfiedLinkError / jboss mbean unable to call native method i n c++ .dll through JNI

I'm loading a .dll with System.load("myAbsolutePath/myDll.dll"); It looks to load it fine ( no error thrown when wrapping the above in a try/catch block ), but when I make the call to a method in the .dll, I get unsatisifed link error.
 
The .dll is in the jboss bin.
 
I have tried System.loadLibrary(dll) with the .dll in the java.library.path. No good.
 
I have tried the call to loadLibrary in a static method and a non static method. No good.
 
I have moved the .dll to the location of the MBean. No good. I looked in the .dll & matched up the name of the method I think i'm calling to the ascii name in the .dll. No good.
 
UGH!

I'm using jboss version 3.0.7_jakarta-tomcat-4.1.24. I downloaded a later version ( 3.2 and 4.0 beta ) which gave me some other deployment dependencies that only obscures the issue.

If anyone has successfully called a JNI .dll from an mbean, please post!

Thanks!


Notice to recipient:

The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity.

If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority.


Notice to recipient:

The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity.

If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority.


Notice to recipient:

The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity.

If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority.


Notice to recipient:

The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity.

If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority.

Reply via email to