tomcat and the working directory

[ian ward]

I've seen several old threads speaking about Tomcat and the working
directory but I haven't seen how this may be set. I believe I need to
do this so that some dlls I am using, which are invoked via jni from my
java/web app, can talk to each other. I can get them going but that's
it. At the moment these dlls are in myapp\WEB-INF\lib, which I assume
is tomcat's java.library.path, otherwise system.loadlibrary can't find
them in the first place.

I have experimented a bit but I think it might be some time before I
hit on it. If I am barking up the wrong tree then I'd appreciate being
gently informed and, well, what do I need to do to keep these dlls
happy?

Thanks
Ian

 

[ian ward]

ian ward a écrit :

I've seen several old threads speaking about Tomcat and the working
directory but I haven't seen how this may be set. I believe I need to
do this so that some dlls I am using, which are invoked via jni from my
java/web app, can talk to each other. I can get them going but that's
it. At the moment these dlls are in myapp\WEB-INF\lib, which I assume
is tomcat's java.library.path, otherwise system.loadlibrary can't find
them in the first place.

I have experimented a bit but I think it might be some time before I
hit on it. If I am barking up the wrong tree then I'd appreciate being
gently informed and, well, what do I need to do to keep these dlls
happy?

Thanks
Ian

I think I can set this using System.setProperty("user.dir",<the right
folder>) but at the moment I am putting this in one of my jsp pages and
I'm not convinced that that will work. How can I be sure that I have
set it so that it provides the reference for my dlls? Does it need to
go in the java class(es) which invoke(s) the dlls?

Hoping there is someone there over the weekend!
Ian

 

[Raymond DeCampo]

ian ward a écrit :



I think I can set this using System.setProperty("user.dir",<the right
folder>) but at the moment I am putting this in one of my jsp pages and
I'm not convinced that that will work. How can I be sure that I have
set it so that it provides the reference for my dlls? Does it need to
go in the java class(es) which invoke(s) the dlls?

You are confusing the concepts of the working directory and the user's
home directory. The working directory is the directory the Java process
was started in. As far as I know, there is no way in Java to change the
working directory once the process starts (although JNI calls could
probably do it).

HTH,
Ray

 

[ian ward]

Raymond DeCampo a écrit :

You are confusing the concepts of the working directory and the user's
home directory. The working directory is the directory the Java process
was started in. As far as I know, there is no way in Java to change the
working directory once the process starts (although JNI calls could
probably do it).

HTH,
Ray

This is good news (my confusion) as it hasn't been getting me anywhere.
The other good news is that I don't want to change the working
directory once the java process has started, I just want it to be right
in the first place - I only made the suggestion about doing it within
java as I assumed (wrongly) that I had the right thing and that I just
needed to find the right place/moment to set it.

The (temporary, I hope) bad news is that you haven't told me how I do
set the working directory. I assume I'm looking for some sort of
environment variable (which one?) and the right place to set it
(whether inside or outside tomcat).

You're not allowed to have a proper weekend until you've told me this!

Many thanks in the meantime

PS I've discovered that my comments about the java.library.path and
tomcat are are bit out but I think I've got that covered now.

 

[Chris Smith]

The (temporary, I hope) bad news is that you haven't told me how I do
set the working directory. I assume I'm looking for some sort of
environment variable (which one?) and the right place to set it
(whether inside or outside tomcat).

This could be set by modifying the Tomcat startup scripts. Note that
it's possible that Tomcat depends on the CWD, so you might break stuff
by trying. Can you not change your code to avoid depending on the CWD?

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[ian ward]

Chris Smith a écrit :

This could be set by modifying the Tomcat startup scripts. Note that
it's possible that Tomcat depends on the CWD, so you might break stuff
by trying. Can you not change your code to avoid depending on the CWD?

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

As far as my understanding goes, this is critical.
Briefly,....
I have been able, while developing in eclipse, to duplicate both the
crash and a smooth run by setting a run configuration argument called
'working directory' which has to be where my jni dlls are living if I
want the latter scenario.
My grasp of the theory is shaky but I believe that this doesn't concern
the java.library.path ie good old PATH - if this is not set correctly
(to include the location of the dlls then System.loadlibary fails with
something like 'your dll isn't in/on java.library.path'.
I get past this ok so now I can see the dlls from the java class but it
seems that when the dlls need to talk to each other, and they do (eg
calling a method on one of them which involves passing a pointer to
another as a method parameter) then I get a crash with a log which
starts like this.....

An unexpected exception has been detected in native code outside the
VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at
PC=0x67462713
Function=[Unknown.]

......this is the identical error I was getting while developing if I
didn't have the 'working directory' set.

If you recognise this scenario and can recommend a 'safe' route then
I'm all ears otherwise it seems I may have only one option - I'm brave
and foolish! Or rather, desperate (btw, I've not written this jni dll
set up and I'm not up to redesigning it, even if it were possible) Now
give....!

Thanks
Ian

 

[ian ward]

Chris Smith a écrit :

This could be set by modifying the Tomcat startup scripts. Note that
it's possible that Tomcat depends on the CWD, so you might break stuff
by trying. Can you not change your code to avoid depending on the CWD?

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

PS. I assure you I'm not reckless by nature and of course I'd look into
any possible consequences, particularly if it means messing with tomcat
which for me is a new toy. While I'm developing this I really need to
know what my options are and at the moment, as I said, I haven't any
and I'm quite blocked.

Thanks for any help
Ian

 

[ian ward]

I believe, with what I have stumbled upon ('stumbled' as it was under
my nose all the time; well, today anyway), I need now just to worry
about java processes and java threads - but I think I can do some
reading for that.
So I can thank you for your help in, as I asked, giving me a subtle
nudge in the right direction.

 

[Chris Uppal]

I get past this ok so now I can see the dlls from the java class but it
seems that when the dlls need to talk to each other, and they do (eg
calling a method on one of them which involves passing a pointer to
another as a method parameter) then I get a crash with a log which
starts like this.....

An unexpected exception has been detected in native code outside the
VM.

This sounds like a straightforward bug in the JNI code, rather than a setup
problem. You have been given buggy DLLs, get onto the supplier and have them
provide a fix.

.....this is the identical error I was getting while developing if I
didn't have the 'working directory' set.

Allow me to correct myself -- you have been given /very/ buggy DLLs.

You /may/ be able to workaround the problem by ensuring that the DLLs are in
Tomcat's "current directory" (and setting the PATH -- or whatever -- such that
they can they can be found there). But I suspect that you'll find that the
problem isn't restricted to the buggy DLLs assuming (without checking) a
certain physical environment and crashing if they don't find it. There's a
fair chance (I'd imagine) that they are also confused about threading issues
and so on, and may not play happily in a "sophisticated" environment such as
Tomcat. That's pure (and somewhat scurrilous) speculation, of course.

-- chris

 

[ian ward]

Chris Uppal a écrit :

This sounds like a straightforward bug in the JNI code, rather than a setup
problem. You have been given buggy DLLs, get onto the supplier and have them
provide a fix.



Allow me to correct myself -- you have been given /very/ buggy DLLs.

You /may/ be able to workaround the problem by ensuring that the DLLs arein
Tomcat's "current directory" (and setting the PATH -- or whatever -- suchthat
they can they can be found there). But I suspect that you'll find that the
problem isn't restricted to the buggy DLLs assuming (without checking) a
certain physical environment and crashing if they don't find it. There'sa
fair chance (I'd imagine) that they are also confused about threading issues
and so on, and may not play happily in a "sophisticated" environment suchas
Tomcat. That's pure (and somewhat scurrilous) speculation, of course.

-- chris

Thanks for your comments. The dlls are home-made, not commercial. Would
it be difficult to fix this 'current directory' bug? Also, is there any
way I can test what you've said about the thread issue? This is not my
area at all but I do need to know about these risks.
Ian

 

[Chris Uppal]

Thanks for your comments. The dlls are home-made, not commercial. Would
it be difficult to fix this 'current directory' bug?

Who knows ? My point is that it's a /bug/ not a configuration error -- no JNI
code should /ever/ produce the error you are seeing. It's program crash, not
a diagnostic error message. The bug might be simple and easy to fix, but the
only people who can fix it are the people who supply the JNI code.

Also, is there any
way I can test what you've said about the thread issue? This is not my
area at all but I do need to know about these risks.

I'm afraid that I can't tell. I'm /suspicious/ of any JNI code that crashes,
and the nature of the crash suggests (but does not imply) that the code's
authors are breaking some of the JNI rules. There are a number of such rules
concerning things like how long a reference to a Java object is valid, and what
can be passed from thread to thread. Of course, the crash may be nothing to do
with JNI at all, it could be caused by any random C++ bug (such as using a
pointer that has been freed). But the JNI rules are relatively easy to get
wrong, so my /guess/ is that that's the most likely source of the problem. If
that /is/ the case, then I suspect threading issues might /also/ be a problem
simply because the threading rules are easy to get wrong (any threaded code is
easy to get wrong, of course, but JNI adds some extra restrictions), hard to
test, and it seems likely that Tomcat is providing a threading environment that
does not resemble the testing environment that the JNI code's authors used (I
wouldn't be surprised if they didn't test threading at all). However the fact
that you can make the code fail from a simple (and, I assume, single-threaded)
test harness implies that there is at least one bug that is /not/
thread-related. You can legitimately /hope/ that fixing that will fix all of
your problems.

I'm sorry not to be more help. Basically, what I am saying is that the only
people who can fix the code are the ones who wrote it, or who have taken
ownership of it since. If you now "own" that code, then I don't think you have
any option but to get involved in JNI coding (not something to look forward to,
I agree...)

-- chris