working with a foreign directory...

[secret]

I'm running a java process on a remote machine. One of the thing the
program does is to read a configuration file (actually a log4j configuration
file) specified as being at \\company\\config\\logconfig.cfg The double
backspaces are for escaping the directory separators and I know I should
have used the separator char but this is the code as I've found it.

My problem is that if I run my START_SERVER script from the drive that
contains the configuration files then all is well. But if I call it from
another drive then it fails to find the configuration script. I can't
specify the file path with the drive letter as it's not guaranteed to be on
the same drive in different environments (qa and production etc).

I thought that the user.dir variable was the issue as it specified itself as
being the drive that I ran the command from, rather than the drive that the
command was located (which I'd like it to be). However, setting the
user.dir in the start_server script doesn't appear to do the trick.

What can I do to locate this file. I briefly tried using a relative path
but that kind of felt like giving up . And it didn't work the first time I
tried it. I suppose if I was going to do that I'd use getResourceAsStream
but the configurator class used by log4j doesn't use streams, though I could
generate the properties myself I suppose.

however, this seems like a very solvable problem. Why isn't Java
recognizing that the drive I want it to use as it's base is the drive that
application started up in, not the drive I called it from?

thanks for your help and time.

 

[Steve W. Jackson]

:I'm running a java process on a remote machine. One of the thing the
rogram does is to read a configuration file (actually a log4j configuration
:file) specified as being at \\company\\config\\logconfig.cfg The double
:backspaces are for escaping the directory separators and I know I should
:have used the separator char but this is the code as I've found it.
:
:My problem is that if I run my START_SERVER script from the drive that
:contains the configuration files then all is well. But if I call it from
:another drive then it fails to find the configuration script. I can't
:specify the file path with the drive letter as it's not guaranteed to be on
:the same drive in different environments (qa and production etc).
:
:I thought that the user.dir variable was the issue as it specified itself as
:being the drive that I ran the command from, rather than the drive that the
:command was located (which I'd like it to be). However, setting the
:user.dir in the start_server script doesn't appear to do the trick.
:
:What can I do to locate this file. I briefly tried using a relative path
:but that kind of felt like giving up . And it didn't work the first time I
:tried it. I suppose if I was going to do that I'd use getResourceAsStream
:but the configurator class used by log4j doesn't use streams, though I could
:generate the properties myself I suppose.
:
:however, this seems like a very solvable problem. Why isn't Java
:recognizing that the drive I want it to use as it's base is the drive that
:application started up in, not the drive I called it from?
:
:thanks for your help and time.
:
:

You're missing a key point about Java: its multiplatform nature makes
it inherently unaware of certain facts about underlying filesystems. It
relies on the native platform for help there.

That path you specified *is* a relative path -- relative to the current
drive. It's one of the failings of the drive-letter-based filesystem of
Windows. So you're going to have no choice but to handle a drive letter
in this situation, or get it off a Windows filesystem.

And you can change the user.dir property all you like, but it doesn't
have any actual affect on your "current working directory". It's set
when you start the application. Perhaps the above location is
considered to be on the same drive as the user's home directory? If so,
you may be able to use the absolute path of a File based on the
user.home property and acquire a drive letter to prepend to that path.

= Steve =