Log to file problem

Discussion in 'Java' started by Petterson Mikael, Jun 21, 2007.

  1. 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
    Petterson Mikael, Jun 21, 2007
    #1
    1. Advertising

  2. Petterson Mikael

    Roedy Green Guest

    On Thu, 21 Jun 2007 12:59:55 +0200, Petterson Mikael
    <> wrote, quoted or indirectly quoted someone who
    said :

    >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.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Jun 21, 2007
    #2
    1. Advertising

  3. Petterson Mikael

    Lew Guest

    Roedy Green wrote:
    > On Thu, 21 Jun 2007 12:59:55 +0200, Petterson Mikael
    > <> wrote, quoted or indirectly quoted someone who
    > said :
    >
    >> 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.


    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.

    --
    Lew
    Lew, Jun 21, 2007
    #3
  4. Lew wrote:
    > Roedy Green wrote:
    >> On Thu, 21 Jun 2007 12:59:55 +0200, Petterson Mikael
    >> <> wrote, quoted or indirectly quoted someone who
    >> said :
    >>
    >>> 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.

    >
    > 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

    --
    TechBookReport Java - http://www.techbookreport.com/JavaIndex.html
    TechBookReport, Jun 21, 2007
    #4
  5. Petterson Mikael

    EricF Guest

    In article <>, TechBookReport <> wrote:
    >Lew wrote:
    >> Roedy Green wrote:
    >>> On Thu, 21 Jun 2007 12:59:55 +0200, Petterson Mikael
    >>> <> wrote, quoted or indirectly quoted someone who
    >>> said :
    >>>
    >>>> 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.

    >>
    >> 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
    >

    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
    EricF, Jun 22, 2007
    #5
  6. Petterson Mikael

    Lew Guest

    EricF wrote:
    > 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.

    --
    Lew
    Lew, Jun 22, 2007
    #6
    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.

Share This Page