Log to file problem

[Petterson Mikael]

Hi,

In a class we have a constant pointing out path to store a log file.

public static final String LOG = "<path to log dir>";

The path is valid only in the context of the target environment and when
we are testing that path is not valid. So when we run the test we get:

java.io.FileNotFoundException: <path to log file> (No such file or
directory) at java.io.FileOutputStream.open

Log dir is created in a "static initializer".

Any ideas how I can change the path depending if it is a test or class
is running in target environment.

What do you think about checking if the path exists and if not change it
to a test directory.


All hints appreciated,

cheers,

//mikael

 

[Roedy Green]

The path is valid only in the context of the target environment and when
we are testing that path is not valid. So when we run the test we get:

I think what you mean is the file moves, in one place for testing and
in another for production.

I would do something like this:

public class Config

public static final PRODUCTION = true;

logURL = PRODUCTION ? "C:/productionplace/log.txt" :
"C:/temp/log.txt";

You must modify PRODUCTION before compiling for production.

 

[Lew]

I think what you mean is the file moves, in one place for testing and
in another for production.

I would do something like this:

public class Config

public static final PRODUCTION = true;

logURL = PRODUCTION ? "C:/productionplace/log.txt" :
"C:/temp/log.txt";

You must modify PRODUCTION before compiling for production.

A cleaner approach is to put the location in a resource file and read in the
Properties at run time, or to use relative paths to emplace the log at a known
and controlled location relative to the application class path.

 

[TechBookReport]

A cleaner approach is to put the location in a resource file and read in
the Properties at run time, or to use relative paths to emplace the log
at a known and controlled location relative to the application class path.

Agreed - possibly with the production path set as the default value
which is used if the property isn't set explicitly.

Pan

 

[EricF]

Agreed - possibly with the production path set as the default value
which is used if the property isn't set explicitly.

Pan

Also agreed. Just did this and used the classloader to load the properties.
Wish I knew a bit of Spring - with all the exceptions that could be thrown and
wanting to default to the production value if things went wrong, the little
bit of code I wrote was very ugly. It would be nice to inject the value,
though Spring would likely be overkill for this.

Eric

 

[Lew]

Also agreed. Just did this and used the classloader to load the properties.
Wish I knew a bit of Spring - with all the exceptions that could be thrown and
wanting to default to the production value if things went wrong, the little
bit of code I wrote was very ugly. It would be nice to inject the value,
though Spring would likely be overkill for this.

If you think handling Exceptions is ugly, try not handling them.

I swear half my production code is comments, half of what remains is safety
checking for things like argument boundaries or wild calculations, half of
what's left after that is exception handling, half of what remains after that
is logging, and only the bit that remains after that actually does the
"happy-path" logic.

The "real world" is fraught with conditions for which your code must be on
guard. Just because it's lengthy doesn't make it ugly. Just because it's
hard work doesn't mean you should skimp on it.