Gordon Beaton was thinking very hard :
>> Java_it_ribes_serialDriver_SerialPort_nativeOpenPort (JNIEnv *env, jobject
>> jobj, jstring port)
[quoted text clipped - 4 lines]
> stored elsewhere. How do you expect to find it later? Please post
> *real* code.
Sorry, I cleaned up a bit the code I posted because the function was
too long, and I suppose I deleted a too much :P. In nativeOpenPort
there was also the instruction "AddSerialPort(SerialPort);" that adds
the object to a list of the current opened ports (see below), and
retrieved in the notifyEvent method with the SearchSerialPort function.
void AddSerialPort(LPSERIALPORT SerialPort)
{
LPPORTLIST newPort = (LPPORTLIST)malloc(sizeof(PORTLIST));
newPort->ComPort = SerialPort;
newPort->Next = openedPorts;
openedPorts = newPort;
}
> In your callback method, have you confirmed that SerialPort != NULL,
> (see prev), that (javaEvent != 0), etc, i.e. that you actually *reach*
> CallVoidMethod()?
Yes
> If so, what does CallVoidMethod() return? What do
> env->ExceptionOccurred() and env->ExceptionDescribe() say?
The java method sometimes seems to be correctly called (no exceptions
thrown), but the data it retrieves is absolutely incorrect. The problem
is that most of times it is not called, but if I open a serial terminal
all data arrived and bufferized is correctly shown on screen...and if I
run the same DLL in a java standalone app all works correctly, the
problem only happens if I load the DLL under tomcat...
> This might also help:
> http://groups.google.com/group/comp.lang.java.programmer/msg/511c52ef88a993c9
Seen it. My jar library is located under %CATALINA_HOME%\shared\lib,
and in my tests (just to avoid problems of this kind) I restarted
tomcat every time.
Thanks for your help.
Gordon Beaton - 10 Apr 2007 12:48 GMT
> The java method sometimes seems to be correctly called (no
> exceptions thrown), but the data it retrieves is absolutely
[quoted text clipped - 3 lines]
> standalone app all works correctly, the problem only happens if I
> load the DLL under tomcat...
Have you confirmed that the data is correct when it reaches the native
callback method, before you call Java?
Have you attempted hardcoding some test data there?
You don't seem to be initializing all of the SerialPort fields.
Remember that memory returned by malloc() is *not* zeroed, and the
actual contents may differ in the different runtime environments.
>> This might also help:
> Seen it.
Hmm, yes I see now that that was you too...
/gordon
--
Elvandar - 10 Apr 2007 13:39 GMT
Gordon Beaton wrote on 10/04/2007 :
>> The java method sometimes seems to be correctly called (no
>> exceptions thrown), but the data it retrieves is absolutely
[quoted text clipped - 8 lines]
>
> Have you attempted hardcoding some test data there?
I find out the problem is not located in my code and/or in something
linked to tomcat. Even if in standalone applications all works well,
the problem is linked with the GSM modem I'm currently using (a Siemens
M20). With other modems (also of the Siemens family, like the TC35) or
simulating a modem on a loopback link, all works well.
Thanks for your help, I'll try to check why the M20 is so hard to
handle :)
Chris Uppal - 10 Apr 2007 13:56 GMT
> The java method sometimes seems to be correctly called (no exceptions
> thrown), but the data it retrieves is absolutely incorrect. The problem
> is that most of times it is not called, but if I open a serial terminal
> all data arrived and bufferized is correctly shown on screen...and if I
> run the same DLL in a java standalone app all works correctly, the
> problem only happens if I load the DLL under tomcat...
The only possibilities I can think of (that you haven't already ruled out) are
that either the machine is running under a higher load with Tomcat (and so may
be missing asynchronous notifications somewhere), or that the threading
environment is different.
I'm a little bit suspicious of the calls to AttachCurrentThread() and
DetachCurrentThread() in your NotifyEvent(). If that is being called at
serial port speeds, and if I'm right in thinking that AttachCurrentThread() is
a relatively heavyweight operation when the thread is not already attached[*],
then that /might/ a source of problems.
-- chris
[*] AFAIK it involves messing around with the target thread's stack.