Capturing console output in a specific log file?

[Slim Slam]

When I launch our Play app in production, I first do "activator dist" and

then launch the app something like this:

$ nohup ./bin/OurFunApp  &

Starting it with "nohup" puts the console output into the file "nohup.out" in the $HOME directory.

If I want the console output to go into, say, /var/log/OurFunApp/console.log, is there a way

to do that with Logback or do I need to start the app like this:

$ nohup ./bin/OurFunApp  >  /var/log/OurFunApp/console.log  &

--J

[Will Sargent]

You would configure this using Logback.

https://www.playframework.com/documentation/2.3.x/SettingsLogger

Will Sargent

Consultant, Professional Services

Typesafe, the company behind Play Framework, Akka and Scala

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Slim Slam]

Hi Will,

    Thanks for your response. It's not clear to me how to get Java statements like:

System.out.println("Checking values for this routine");

   to end up in a log file using Logback or even to get Java exceptions to end up in a log file.

 I've read the Play documentation page that you suggested but I don't see the solution there.

  Any suggestions?

J

[Igmar Palsenberg]

 

    Thanks for your response. It's not clear to me how to get Java statements like:

System.out.println("Checking values for this routine");

   to end up in a log file using Logback or even to get Java exceptions to end up in a log file.

 I've read the Play documentation page that you suggested but I don't see the solution there.

  Any suggestions?

Yeah, don't use System.out.*. Use Logger, of ALogger to log something. That's where those classes are for. Then you configure in detail what happens to the stuff it generates..

Igmar 

[Will Sargent]

Play uses Logback for logging.  Logback writes to a ConsoleAppender.

You should never use System.out.println directly, not even in debugging.  Use logger.debug instead.

If you have a library which does write to System.out.println directly and cannot modify it (I'm looking at you, JSSE), then you can override it in the last ditch effort:

https://blogs.oracle.com/xuelei/entry/jsse_debug_logging_with_timestamp

but this is unsafe on all sorts of levels.  Using sysout redirection at the console as you described is far safer.

Will Sargent

Consultant, Professional Services

Typesafe, the company behind Play Framework, Akka and Scala

[Igmar Palsenberg]

 

Yeah, don't use System.out.*. Use Logger, of ALogger to log something. That's where those classes are for. Then you configure in detail what happens to the stuff it generates..

Not to mention that stdout is buffered by default, and it it points to a console, it's probably going to block.

Igmar 

[Brandon Arp]

While I agree with Will and Igmar, I find myself in the same situation as Slim.  If you've ever messed up a logback config, you'll find yourself wanting a file for the console output.  If you've ever used a library that wasn't well behaved with regards to logging, you're going to want it.  If you've ever had a PID file problem, that debug goes to stdout.  There are numerous other situations where you want to know where something went wrong where the output can go to stdout.  I'm not advocating logging to stdout, but I've always used the redirect (actually, I use 2>&1 >> console.log).  The important part is that I *know* I'm not missing anything that could help me diagnose a problem.  Ideally, that file is empty, but every once in a while it contains useful info.

To directly answer Slim's question: there is a bit of time before logback starts up where things can be logged to the console.  It's not much, but that is probably where you'll see failures that prevent your app from starting.  I recommend you do the redirect to make sure you don't miss them.

Brandon

[Slim Slam]

Is there a way to capture Java Exceptions into a log file other than redirecting the nohup output? 

J

[Slim Slam]

Does adding this code to the Global.java file  look like a way to capture all Java exceptions to the default play "application" logger?

public class Global extends GlobalSettings {


......


    public Promise<Result> onError(RequestHeader request, Throwable t) {
        return Promise.<Result>pure(internalServerError(
            Logger.error(t);
        ));
    }


.........


}

[Will Sargent]

No, because any code you include could do something as simple as e.printStackTrace() and write to System.err directly.

You need to set up a custom PrintStream that prints output to a file somewhere, as described in this URL:

http://stackoverflow.com/questions/14715748/redirect-system-out-and-system-err

Or write a custom shell script to redirect STDOUT and STDERR.

Will Sargent

Consultant, Professional Services

Typesafe, the company behind Play Framework, Akka and Scala

[Slim Slam]

Hi Will,

The code below seems to work ok for Exceptions that occur in Java code that we've written though it doesn't handle Java exceptions

that come from included libraries. It uses the default logger to log the Exception. Is there a problem with this approach?

public Promise<Result> onError(RequestHeader request, Throwable t) {

        Logger.error("Request: " + request + " Location: " + t.toString());
        return Promise.<Result>pure(internalServerError(
            views.html.errorPage.render(t, request.toString())
        ));
    }

The views page looks like this:

@(t: Throwable, rh: String)

@import helper._
@import views.html.helper._

@main(Messages("An Exception Occurred - Doh!")) {

    <h1>AN ERROR OCCURRED! </h1>
     <p></p>
     <strong>An error occurred that we could not prevent. We are sorry about that. The details of the error are below. Perhaps you could send it to us?</strong>
     
     <h3>The Details Should Be Below</h3>
     <h4>error message:</h4>
     @t.getMessage
     <h4>location:</h4>
     @t.toString
     <h4>request:</h4>
     @rh
}