tomcat and the working directory

Discussion in 'Java' started by ian ward, Jun 24, 2005.

  1. ian ward

    ian ward Guest

    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, Jun 24, 2005
    #1
    1. Advertising

  2. ian ward

    ian ward Guest

    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
    ian ward, Jun 25, 2005
    #2
    1. Advertising

  3. ian ward wrote:
    >
    > 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?
    >


    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

    --
    XML is the programmer's duct tape.
    Raymond DeCampo, Jun 25, 2005
    #3
  4. ian ward

    ian ward Guest

    Raymond DeCampo a écrit :
    > ian ward wrote:
    > >
    > > 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?
    > >

    >
    > 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
    >
    > --
    > XML is the programmer's duct tape.


    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.
    ian ward, Jun 25, 2005
    #4
  5. ian ward

    Chris Smith Guest

    ian ward <> wrote:
    > 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
    Chris Smith, Jun 25, 2005
    #5
  6. ian ward

    ian ward Guest

    Chris Smith a écrit :
    > ian ward <> wrote:
    > > 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


    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, Jun 25, 2005
    #6
  7. ian ward

    ian ward Guest

    Chris Smith a écrit :
    > ian ward <> wrote:
    > > 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


    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, Jun 25, 2005
    #7
  8. ian ward

    ian ward Guest

    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.
    ian ward, Jun 25, 2005
    #8
  9. ian ward

    Chris Uppal Guest

    ian ward wrote:

    > 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
    Chris Uppal, Jun 26, 2005
    #9
  10. ian ward

    ian ward Guest

    Chris Uppal a écrit :
    > ian ward wrote:
    >
    > > 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 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
    ian ward, Jun 27, 2005
    #10
  11. ian ward

    Chris Uppal Guest

    ian ward wrote:

    > 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
    Chris Uppal, Jun 29, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matthew Macchia
    Replies:
    3
    Views:
    1,051
    Roedy Green
    Apr 13, 2004
  2. Priyanka AGARWAL
    Replies:
    9
    Views:
    9,944
    Gordon Beaton
    May 25, 2004
  3. Katerina McLean
    Replies:
    1
    Views:
    3,063
    Juha Laiho
    Dec 10, 2004
  4. twins
    Replies:
    1
    Views:
    5,830
  5. gavino
    Replies:
    0
    Views:
    1,274
    gavino
    Oct 29, 2006
Loading...

Share This Page