Menu

#24 stdout, stderr redirect capability

v3.0.1
open
5
2003-04-28
2003-04-28
Anonymous
No

I'm migrating from some homegrown scripts for
linux/win32 to java service wrapper and I used to
redirect STDOUT and STDERR to simple files by appending
> app.output 2> app.errors to the command line.

It appears I cant to that anymore? It would be nice if
maybe there were some extra .conf settings to support this?

Discussion

  • Leif Mortenson

    Leif Mortenson - 2003-04-28

    Logged In: YES
    user_id=228081

    You can get this functionality by redirecting the System.out
    and System.err Print Streams from within the JVM.

    Create your own class that extends PrintStream and simply
    writes anything printed to the stream to a specific file.
    Then call System.setOut and System.setErr with instances of
    your class.

    I used this method a long time ago to create a simple
    logging tool. Before all the current logging tools were
    available.

    Overriding the output PrintStreams should allow you to
    capture pretty much all of your JVM output. I don't think
    it will capture any fatal JVM crash errors as they are
    printed to the error stream as the JVM is dying. But they
    would be captured in the wrapper.log file still.

    Let me know if this will meet your needs. You are unable
    to redirect the output and error output using redirects as
    you described above because the Wrapper is launching the
    Java process directly rather than using a shell. This means
    that shell functions are not available.

    It would be possible to implement what you are asking for
    within the Wrapper but would involve adding new properties
    to the wrapper.conf for each output stream. I would then
    also need properties to configure whether or not the output
    was also sent to the console, wrapper log file, syslog
    etc... I would like to keep the logging configuration from
    getting any more complicated. so am hoping that the above
    work around will work for you.

    It is really designed to make it possible to log fatal
    errors and basic startup messages that may not be possible
    to log from within the JVM. Writing yet another complicated
    logging tool is something that I would like to avoid if
    possible.

    Cheers,
    Leif

     
  • Leif Mortenson

    Leif Mortenson - 2003-04-28
    • labels: --> Configuration
    • milestone: --> v3.0.1
    • assigned_to: nobody --> mortenson
     
  • Alessandro Staltari

    Logged In: YES
    user_id=53112

    I'd like this feature too.
    Probably the best thing would be having "jvm-out 1" and
    "jvm-err 1" as log prefix mantaining a single log file that
    could be split using grep o a similar command if needed.

    Are there plans to implement this?

     
  • Leif Mortenson

    Leif Mortenson - 2004-06-22

    Logged In: YES
    user_id=228081

    This is still on my todo list. It will involve a rework of
    the way output is piped from the JVM to the Wrapper proess
    however and is thus not as simple as one would think. Not
    forgotten though.

    Cheers,
    Leif

     
  • Davy Boy

    Davy Boy - 2006-03-14

    Logged In: YES
    user_id=1467052

    I know an old feature, but bumping a little. My take on this
    would be to have the System.out to be logged as

    INFO | jvm 1 | 2006/03/14 15:19:28 | .....

    and the System.err to be logged as

    ERROR | jvm 1 | 2006/03/14 15:19:28 | .....

    The reason I argue for this instead of jvm-out and jvm-err,
    is that you should be able to see more clearly (i.e. caps
    and start of line) those lines in the log which are errors,
    such as Exception dumps, and custom err messages. Plus I
    think its a bit easier to write a RegEx testing on the start
    of a line, rather that finding jvm-err in the middle of a
    line. (I know I know, I can figure it out, but its just
    easier :-)).

    Thanks Leif,

    David Hayes

     

Log in to post a comment.