scala binary and logging

[Sam Halliday]

Hi all,

I've had a discussion with the author of SBT and he believes that the scala binary is doing something funny to the classpath and/or logging settings

  https://github.com/sbt/sbt/issues/702

Basically, if one passes -Djava.util.logging.config.file=logging.properties as a parameter to the scala binary, it is silently ignored.

In comparison, if the java binary is called, and the scala library added to the classpath, all works as expected.

Could somebody please shed some light on this, because this bug means that the scala binary (and SBT by extension) is effectively disabled from using the Java Util Logging (JUL) library until it is fixed.

Best regards,

Sam

[Som Snytt]

As a data point, WFM, with a trivial app and local logging.properties, java 7, scala 2.10.1:

apm@halyard ~/tmp/jul
$ scala -Djava.util.logging.config.file=logging.properties myapp.MyApp
Apr 04, 2013 2:52:01 PM myapp.MyApp$delayedInit$body apply
INFO: Some info
Apr 04, 2013 2:52:01 PM myapp.MyApp$delayedInit$body apply
FINE: Some fine
Apr 04, 2013 2:52:01 PM myapp.MyApp$delayedInit$body apply
FINER: Some finer

I see on the issue that you're talking about forked tests in sbt?

Also, maybe you've set something in your env?

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

[Samuel Halliday]

Som,

It is forked tests and main "run"ning from SBT. There is a standalone example further down.

--
Sam

[Som Snytt]

The scala runner works hard to keep cwd off the classpath. 

# If using the boot classpath, also pass an empty classpath
# to java to suppress "." from materializing.

Here's one way to restore it at the command line.  That's the windows path sep on cygwin.  The output is from a trivial formatter.

$ scala -toolcp \; -Djava.util.logging.config.file=logging.properties myapp.MyApp
!!! What the --?

I seem to remember that many years ago, I had to write code to config JUL for unit tests and not rely on the static initializers.

If you were looking for a reason not to use JUL, this would be one of many:

    Formatter getFormatterProperty(String name, Formatter defaultValue) {
        String val = getProperty(name);
        try {
            if (val != null) {
                Class clz = ClassLoader.getSystemClassLoader().loadClass(val);
                return (Formatter) clz.newInstance();
            }
        } catch (Exception ex) {
            // We got one of a variety of exceptions in creating the
            // class or creating an instance.
            // Drop through.
        }
        // We got an exception.  Return the defaultValue.
        return defaultValue;
    }

Yawn! Error handling is so boring, we'll just drop through.

Here's another way to break logging config:

object MyApp extends App {
  java.lang.System setOut null
  val logger = Logger.getLogger("myapp.log")
  logger info "Some info"
}

Scala's policy is analogous to Java's.

    /** Against my better judgment, giving in to martin here and allowing
     *  CLASSPATH to be used automatically.  So for the user-specified part
     *  of the classpath:
     *
     *  - If -classpath or -cp is given, it is that
     *  - Otherwise, if CLASSPATH is set, it is that
     *  - If neither of those, then "." is used.
     */
    def userClassPath = (
      if (!settings.classpath.isDefault)
        settings.classpath.value
      else sys.env.getOrElse("CLASSPATH", ".")
    )

// Loosely based on the draft specification at:
// https://wiki.scala-lang.org/display/SIW/Classpath

On Thu, Apr 4, 2013 at 3:09 PM, Samuel Halliday <sam.ha...@gmail.com> wrote:

Som,

Try making your local logging.properties do something non-trivial, like loading a custom formatter and the problem will show itself.

--
Sam

[Samuel Halliday]

Som,

The issue can also be reproduced if the full filename is passed, so it isn't about CWD.

I have a demo project that shows this problem (and also to discuss some unrelated stacetrace filtering issues with specs2)

https://github.com/fommil/specs2-exceptions


The "workaround" is that the SBT author is going to use the java binary instead of the scala binary to launch applications from forked processes. Obviously, a solution within the scala binary / launcher would be preferable.


Regarding your comments on JUL - I agree the internals are very ugly and the default filters / formatters aren't very user friendly. However, with custom filters / formatters I've found JUL does the job, so I'm not inclined to reach for a third party. The real problem is that there isn't a Scala logging facility yet (which would have to be part of the SLF4J stack to integrate with legacy Java code). I have gone through pains to use the Akka LoggingAdapter with JUL for my logging needs. The advantage of using JUL is that it comes as standard in the JVM and can be rerouted to SLF4J by anyone who really hates it. More here https://github.com/janm399/akka-patterns/wiki/Lessons-Learnt---Fommil

--
Sam

[Som Snytt]

On Fri, Apr 5, 2013 at 1:04 AM, Samuel Halliday <sam.ha...@gmail.com> wrote:

The issue can also be reproduced if the full filename is passed, so it isn't about CWD.

The problem is that the custom Formatter isn't seen by the system class loader; from the command line, adding cwd with scala -toolcp is a work around for that.

(I wasn't talking about the config.file path.)

Thanks for the Lessons post, which I had read; my opinion about JUL used to align with yours.