You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@daffodil.apache.org by "stevedlawrence (via GitHub)" <gi...@apache.org> on 2023/02/08 15:26:46 UTC
[GitHub] [daffodil] stevedlawrence opened a new pull request, #954: Use SLF4J for Daffodil logging, with custom backend for CLI/TDML
stevedlawrence opened a new pull request, #954:
URL: https://github.com/apache/daffodil/pull/954
- Remove all uses of log4j. Instead, Daffodil now uses SLF4J (MIT license) via the scala-logging library (ALv2 licnse). This makes Daffodil more flexible as to which logging backend is used. Additionally, SLF4J has a simpler backend API, so creating custom backends is much more straightforward.
- Implement a custom SLF4J backend via a custom ServiceProvider, LoggerFactory, and Logger that supports thread specific log Levels and PrintStreams. Note that each thread must explicitly configure the logger with the level and stream, or else this new backend silently drops log messages.
- Put this new SLF4J backend on the CLI classpath so the CLI uses this thread safe logging, needed for parallel tests.
- Put this new SLF4J backend on the TDML processor classpath. The TDML Runner does not currently configure this new logger, so logs are just dropped (essentially the same behavior as we have now), but this avoids error messages from SLF4J about not having a logger available. It also means in the future we can easily configure this logger to give the TDML runner the ability to capture and expect log messages. Additionally, this resolves errors when the log4j-api version did not match a log4j-core version defined in a DFDL schema project. The TDML runner now requires this custom backend, so users do no need to specify one.
- Put this new SLF4J backend on all other subprojects in the test configuration. This way, if a unit test runs code hat logs, then it ensures a logger is available and avoids an SLF4J warning. Note however that since no tests configure the logger, the logs will be dropped. Also note that this is only for the "test" configuration, not "compile" or "runtime", and so API users must add a custom SFL4J backend or they will get a warning from SLF4J. This is similar to the existing behavior where users needed to add a log4j backend, but avoids API mismatches since SLF4J has better backwards compatibility.
- Because the custom logger is used for the TDML runner as well, there are no longer any issues with DFDL schema projects depending on a different version of log4j than is used by Daffodil. If they already depend on log4j with this update, it will simply not be used.
- Also correct subprojets made up of tdml tests to depend on tdmlProc in the "test" configuration. This doesn't really matter but is technically correct.
- Change the CLI Main object to a class that can be instantiated with custom streams instead of sharing global mutable state. The Main object now just creates an instance using normal stdin/out/err, but tests create a Main instance using test/thread specific streams.
- Modify the CLI to configure the custom SLF4J logger so different instances that are run in different threads can log to a different streams and levels.
- These changes now make CLI tests completely thread safe, so parallel CLI tests are enabled.
Backwards/Compatibility:
Daffodil now uses SLF4J for logging instead of log4j. API users may need to add a new dependency to specify which logging backend to use, for example slf4j-log4j for the previous behavior. If no backend is found, a warning will be output to stderr and log messages will be dropped.
DFDL schema projects that previously added log4j-core (or another log4j implementation) as a dependency to avoid warnings no longer need that dependency--a custom Daffodil specific logger is now used for TDML tests and is automatically pulled in as dependency.
DAFFODIL-2778, DAFFODIL-2787
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil] stevedlawrence merged pull request #954: Use SLF4J for Daffodil logging, with custom backend for CLI/TDML
Posted by "stevedlawrence (via GitHub)" <gi...@apache.org>.
stevedlawrence merged PR #954:
URL: https://github.com/apache/daffodil/pull/954
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil] stevedlawrence commented on a diff in pull request #954: Use SLF4J for Daffodil logging, with custom backend for CLI/TDML
Posted by "stevedlawrence (via GitHub)" <gi...@apache.org>.
stevedlawrence commented on code in PR #954:
URL: https://github.com/apache/daffodil/pull/954#discussion_r1101421269
##########
daffodil-slf4j-logger/src/main/scala/org/apahe/daffodil/slf4j/DaffodilSLF4JLogger.scala:
##########
@@ -0,0 +1,156 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.daffodil.slf4j
+
+import java.io.PrintStream
+import java.util.concurrent.ConcurrentHashMap
+
+import org.slf4j.ILoggerFactory
+import org.slf4j.IMarkerFactory
+import org.slf4j.Logger
+import org.slf4j.Marker
+import org.slf4j.event.Level
+import org.slf4j.helpers.BasicMarkerFactory
+import org.slf4j.helpers.LegacyAbstractLogger
+import org.slf4j.helpers.MessageFormatter
+import org.slf4j.helpers.NOPMDCAdapter
+import org.slf4j.spi.MDCAdapter
+import org.slf4j.spi.SLF4JServiceProvider
+
+class DaffodilSLF4JServiceProvider extends SLF4JServiceProvider {
+ override lazy val getLoggerFactory: ILoggerFactory = new DaffodilLoggerFactory()
+ override lazy val getMarkerFactory: IMarkerFactory = new BasicMarkerFactory()
+ override lazy val getMDCAdapter: MDCAdapter = new NOPMDCAdapter()
+ override lazy val getRequestedApiVersion: String = "2.0.99"
+ override def initialize(): Unit = {}
+}
+
+class DaffodilLoggerFactory extends ILoggerFactory {
+
+ private val loggerMap = new ConcurrentHashMap[String, DaffodilLogger]()
+
+ override def getLogger(name: String): Logger = {
+ val daffodilLogger = loggerMap.get(name)
+ if (daffodilLogger != null) {
+ daffodilLogger
+ } else {
+ val newInstance = new DaffodilLogger(name)
+ val oldInstance = loggerMap.putIfAbsent(name, newInstance)
+ if (oldInstance == null) {
+ newInstance
+ } else {
+ oldInstance
+ }
+ }
+ }
+}
+
+/**
+ * A logger that should only be used by specifically by Daffodil (e.g. CLI, TDML
+ * Runner) to support thread specific log levels and log streams. This is mostly
+ * useful for testing where we want to allow each test thread to log at a
+ * different level and stream. To set the level and stream, one should call:
+ *
+ * daffodilLogger.setThreadLoggerConfig(level, stream)
+ *
+ * When done, the config should be removed by calling:
+ *
+ * daffodilLogger.removeThreadLoggerConfig()
+ */
+class DaffodilLogger(name: String) extends LegacyAbstractLogger {
Review Comment:
I actually based this off of the `SimpleLogger`, which also uses the `LegacyAbstractLogger`. The only difference between `AbstractLogger` and `LegacyAbstractLogger` is that it implements the `is<Level>Enabled` functions that accepts a `Marker`, and calls the `is<Level>Enabled` function that doesn't accept a `Marker`.
https://github.com/qos-ch/slf4j/blob/master/slf4j-api/src/main/java/org/slf4j/helpers/LegacyAbstractLogger.java
I imagine this is called "legacy" because slf4j didn't always support markers.
We don't use markers in our daffodil logging, so if we extended AbstractLogger instead we would just have to implement the same code that LegacyAbstractLogger implements. I'll add a comment to make this clear in the code. Agreed that when "legacy" shows up it's often a red flag.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil] stevedlawrence commented on a diff in pull request #954: Use SLF4J for Daffodil logging, with custom backend for CLI/TDML
Posted by "stevedlawrence (via GitHub)" <gi...@apache.org>.
stevedlawrence commented on code in PR #954:
URL: https://github.com/apache/daffodil/pull/954#discussion_r1101410772
##########
build.sbt:
##########
@@ -47,30 +68,34 @@ lazy val macroLib = Project("daffodil-macro-lib", file("daffodil-macro-l
lazy val propgen = Project("daffodil-propgen", file("daffodil-propgen")).configs(IntegrationTest)
.settings(commonSettings, nopublish)
+lazy val slf4jLogger = Project("daffodil-slf4j-logger", file("daffodil-slf4j-logger")).configs(IntegrationTest)
+ .settings(commonSettings)
+ .settings(libraryDependencies ++= Dependencies.slf4jAPI)
+
Review Comment:
Yeah, its all about making it easier to control when this backend is used.
The only projects that need a `runtime` dependency on this custom sl4fj backend are the CLI and TDML processor since those actually need this special thread specific logging. All the other projects should not have a runtime dependency to this backed because API users need the ability to plug in whatever backend they want (logback, log4j, JUL, etc). If we make it part of the actual library, and an API users adds a custom backend, then there will be two backends on the classpath and slf4j will output a warning and just pick whatever backend it sees first, which might not be the one the user wanted. Note that these projects do want to use it as a `test` dependency, otherwise slf4j complains that no backend is available. We could alternatively give them a `test` dependency to something like `slf4j-simple`, but that makes it difficult to capture logs if we some unit test ever wants to, and I figure it's better to eat our own dogfood.
So in short, making it a separate project makes it easier to make it a runtime dependency for daffodil-cli and daffodil-tdml-processor, and a test dependency for all the other jars.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil] stevedlawrence commented on a diff in pull request #954: Use SLF4J for Daffodil logging, with custom backend for CLI/TDML
Posted by "stevedlawrence (via GitHub)" <gi...@apache.org>.
stevedlawrence commented on code in PR #954:
URL: https://github.com/apache/daffodil/pull/954#discussion_r1101441117
##########
daffodil-slf4j-logger/src/main/scala/org/apahe/daffodil/slf4j/DaffodilSLF4JLogger.scala:
##########
@@ -0,0 +1,156 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.daffodil.slf4j
+
+import java.io.PrintStream
+import java.util.concurrent.ConcurrentHashMap
+
+import org.slf4j.ILoggerFactory
+import org.slf4j.IMarkerFactory
+import org.slf4j.Logger
+import org.slf4j.Marker
+import org.slf4j.event.Level
+import org.slf4j.helpers.BasicMarkerFactory
+import org.slf4j.helpers.LegacyAbstractLogger
+import org.slf4j.helpers.MessageFormatter
+import org.slf4j.helpers.NOPMDCAdapter
+import org.slf4j.spi.MDCAdapter
+import org.slf4j.spi.SLF4JServiceProvider
+
+class DaffodilSLF4JServiceProvider extends SLF4JServiceProvider {
+ override lazy val getLoggerFactory: ILoggerFactory = new DaffodilLoggerFactory()
+ override lazy val getMarkerFactory: IMarkerFactory = new BasicMarkerFactory()
+ override lazy val getMDCAdapter: MDCAdapter = new NOPMDCAdapter()
+ override lazy val getRequestedApiVersion: String = "2.0.99"
+ override def initialize(): Unit = {}
+}
+
+class DaffodilLoggerFactory extends ILoggerFactory {
+
+ private val loggerMap = new ConcurrentHashMap[String, DaffodilLogger]()
+
+ override def getLogger(name: String): Logger = {
+ val daffodilLogger = loggerMap.get(name)
+ if (daffodilLogger != null) {
+ daffodilLogger
+ } else {
+ val newInstance = new DaffodilLogger(name)
+ val oldInstance = loggerMap.putIfAbsent(name, newInstance)
+ if (oldInstance == null) {
+ newInstance
+ } else {
+ oldInstance
+ }
+ }
+ }
+}
+
+/**
+ * A logger that should only be used by specifically by Daffodil (e.g. CLI, TDML
+ * Runner) to support thread specific log levels and log streams. This is mostly
+ * useful for testing where we want to allow each test thread to log at a
+ * different level and stream. To set the level and stream, one should call:
+ *
+ * daffodilLogger.setThreadLoggerConfig(level, stream)
+ *
+ * When done, the config should be removed by calling:
+ *
+ * daffodilLogger.removeThreadLoggerConfig()
+ */
+class DaffodilLogger(name: String) extends LegacyAbstractLogger {
Review Comment:
On second thought, it's trivial to implement those extra functions even if it's a bit of extra code. It's probably better to not have to explain why we are using a "legacy" thing and just extend AbstractLogger and implement those 5 functions ourselves.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil] stevedlawrence commented on a diff in pull request #954: Use SLF4J for Daffodil logging, with custom backend for CLI/TDML
Posted by "stevedlawrence (via GitHub)" <gi...@apache.org>.
stevedlawrence commented on code in PR #954:
URL: https://github.com/apache/daffodil/pull/954#discussion_r1101399301
##########
build.sbt:
##########
@@ -36,7 +36,28 @@ lazy val genExamples = taskKey[Seq[File]]("Generate runtime2 example files")
lazy val daffodil = project.in(file(".")).configs(IntegrationTest)
.enablePlugins(JavaUnidocPlugin, ScalaUnidocPlugin)
- .aggregate(macroLib, propgen, lib, io, runtime1, runtime1Unparser, runtime1Layers, runtime2, core, japi, sapi, tdmlLib, tdmlProc, cli, udf, schematron, test, testIBM1, tutorials, testStdLayout)
+ .aggregate(
+ macroLib,
+ propgen,
+ slf4jLogger,
+ lib,
+ io,
+ runtime1,
+ runtime1Unparser,
+ runtime1Layers,
+ runtime2,
+ core,
+ japi,
+ sapi,
+ tdmlLib,
+ tdmlProc,
+ cli,
+ udf,
+ schematron,
+ test,
+ testIBM1,
+ tutorials,
+ testStdLayout)
Review Comment:
Nope, order doesn't matter in the aggregate() function. Makes sense to sort them.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil] tuxji commented on a diff in pull request #954: Use SLF4J for Daffodil logging, with custom backend for CLI/TDML
Posted by "tuxji (via GitHub)" <gi...@apache.org>.
tuxji commented on code in PR #954:
URL: https://github.com/apache/daffodil/pull/954#discussion_r1100685961
##########
build.sbt:
##########
@@ -36,7 +36,28 @@ lazy val genExamples = taskKey[Seq[File]]("Generate runtime2 example files")
lazy val daffodil = project.in(file(".")).configs(IntegrationTest)
.enablePlugins(JavaUnidocPlugin, ScalaUnidocPlugin)
- .aggregate(macroLib, propgen, lib, io, runtime1, runtime1Unparser, runtime1Layers, runtime2, core, japi, sapi, tdmlLib, tdmlProc, cli, udf, schematron, test, testIBM1, tutorials, testStdLayout)
+ .aggregate(
+ macroLib,
+ propgen,
+ slf4jLogger,
+ lib,
+ io,
+ runtime1,
+ runtime1Unparser,
+ runtime1Layers,
+ runtime2,
+ core,
+ japi,
+ sapi,
+ tdmlLib,
+ tdmlProc,
+ cli,
+ udf,
+ schematron,
+ test,
+ testIBM1,
+ tutorials,
+ testStdLayout)
Review Comment:
Does the order matter, or can the lines be sorted alphabetically?
##########
project/Dependencies.scala:
##########
@@ -30,9 +30,11 @@ object Dependencies {
"xml-resolver" % "xml-resolver" % "1.2",
"commons-io" % "commons-io" % "2.11.0",
"com.typesafe" % "config" % "1.4.2",
- "org.apache.logging.log4j" %% "log4j-api-scala" % "12.0",
- "org.apache.logging.log4j" % "log4j-api" % "2.19.0",
- "org.apache.logging.log4j" % "log4j-core" % "2.19.0" % "it,test",
+ "com.typesafe.scala-logging" %% "scala-logging" % "3.9.4",
Review Comment:
Is Daffodil really using anything from the scala-logging library? The calls I see seem to be going directly to the underlying SLF4J Java classes.
Actually, we do use scalalogging.Logger as the type of logger.log, so we're indeed using that library whenever code calls logger.log.info(...).
##########
daffodil-cli/src/conf/.keep:
##########
@@ -0,0 +1,14 @@
+# Licensed to the Apache Software Foundation (ASF) under one or more
Review Comment:
Why do we want to keep the `daffodil-cli/src/conf` directory around if we don't need a logging configuration file anymore? Is the conf directory used as a placeholder for other configuration files that Daffodil will read if it finds them in that directory (within the built product)?
##########
build.sbt:
##########
@@ -47,30 +68,34 @@ lazy val macroLib = Project("daffodil-macro-lib", file("daffodil-macro-l
lazy val propgen = Project("daffodil-propgen", file("daffodil-propgen")).configs(IntegrationTest)
.settings(commonSettings, nopublish)
+lazy val slf4jLogger = Project("daffodil-slf4j-logger", file("daffodil-slf4j-logger")).configs(IntegrationTest)
+ .settings(commonSettings)
+ .settings(libraryDependencies ++= Dependencies.slf4jAPI)
+
Review Comment:
What are the benefits of putting slf4jLogger in its own module as opposed to core or lib? Easier compilation? More fine-grained dependency management?
##########
daffodil-slf4j-logger/src/main/scala/org/apahe/daffodil/slf4j/DaffodilSLF4JLogger.scala:
##########
@@ -0,0 +1,156 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.daffodil.slf4j
+
+import java.io.PrintStream
+import java.util.concurrent.ConcurrentHashMap
+
+import org.slf4j.ILoggerFactory
+import org.slf4j.IMarkerFactory
+import org.slf4j.Logger
+import org.slf4j.Marker
+import org.slf4j.event.Level
+import org.slf4j.helpers.BasicMarkerFactory
+import org.slf4j.helpers.LegacyAbstractLogger
+import org.slf4j.helpers.MessageFormatter
+import org.slf4j.helpers.NOPMDCAdapter
+import org.slf4j.spi.MDCAdapter
+import org.slf4j.spi.SLF4JServiceProvider
+
+class DaffodilSLF4JServiceProvider extends SLF4JServiceProvider {
+ override lazy val getLoggerFactory: ILoggerFactory = new DaffodilLoggerFactory()
+ override lazy val getMarkerFactory: IMarkerFactory = new BasicMarkerFactory()
+ override lazy val getMDCAdapter: MDCAdapter = new NOPMDCAdapter()
+ override lazy val getRequestedApiVersion: String = "2.0.99"
+ override def initialize(): Unit = {}
+}
+
+class DaffodilLoggerFactory extends ILoggerFactory {
+
+ private val loggerMap = new ConcurrentHashMap[String, DaffodilLogger]()
+
+ override def getLogger(name: String): Logger = {
+ val daffodilLogger = loggerMap.get(name)
+ if (daffodilLogger != null) {
+ daffodilLogger
+ } else {
+ val newInstance = new DaffodilLogger(name)
+ val oldInstance = loggerMap.putIfAbsent(name, newInstance)
+ if (oldInstance == null) {
+ newInstance
+ } else {
+ oldInstance
+ }
+ }
+ }
+}
+
+/**
+ * A logger that should only be used by specifically by Daffodil (e.g. CLI, TDML
+ * Runner) to support thread specific log levels and log streams. This is mostly
+ * useful for testing where we want to allow each test thread to log at a
+ * different level and stream. To set the level and stream, one should call:
+ *
+ * daffodilLogger.setThreadLoggerConfig(level, stream)
+ *
+ * When done, the config should be removed by calling:
+ *
+ * daffodilLogger.removeThreadLoggerConfig()
+ */
+class DaffodilLogger(name: String) extends LegacyAbstractLogger {
Review Comment:
Should we be concerned about the "Legacy" word in "LegacyAbstractLogger"? I took a quick look at other Logger subclasses provided by slf4j and noticed that slf4j provides [SubstituteLogger](https://www.slf4j.org/api/org/slf4j/helpers/SubstituteLogger.html) which allows you to set a delete logger (the setDelete(logger) method) and logs to NOPLogger otherwise. However, I'm not sure using `SubstituteLogger` would simplify this code. We still would need a Logger implementation for writing to a PrintStream and [SimpleLogger](https://www.slf4j.org/api/org/slf4j/simple/SimpleLogger.html) doesn't seem to take a PrintStream as a constructor argument. What you have in this class looks simple enough anyway.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil] stevedlawrence commented on a diff in pull request #954: Use SLF4J for Daffodil logging, with custom backend for CLI/TDML
Posted by "stevedlawrence (via GitHub)" <gi...@apache.org>.
stevedlawrence commented on code in PR #954:
URL: https://github.com/apache/daffodil/pull/954#discussion_r1101428479
##########
project/Dependencies.scala:
##########
@@ -30,9 +30,11 @@ object Dependencies {
"xml-resolver" % "xml-resolver" % "1.2",
"commons-io" % "commons-io" % "2.11.0",
"com.typesafe" % "config" % "1.4.2",
- "org.apache.logging.log4j" %% "log4j-api-scala" % "12.0",
- "org.apache.logging.log4j" % "log4j-api" % "2.19.0",
- "org.apache.logging.log4j" % "log4j-core" % "2.19.0" % "it,test",
+ "com.typesafe.scala-logging" %% "scala-logging" % "3.9.4",
Review Comment:
Yep, we use the `scala.logging.Logger`. It's just a very thin wrapper around an SLF4J logger, but the benefit is that if you do something like this:
```scala
Logger.debug.info(s"Some log message $with $some $expensive $variables")
```
Then using macros the ScalaLogger converts it to this:
```scala
if (Logger.isDebugEnabled) Logger.log.debug(s"Some log message $with $some $expensive $variables")
```
This way if the debug log level isn't enabled, we never evaluate the string with potentially expensive variables. If we don't have this wrapper and use SLF4J directly, then we either need to manually wrap all our log calls in conditionals or we'll just always evaluate the strings. So using scala-logging should be faster.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil] stevedlawrence commented on a diff in pull request #954: Use SLF4J for Daffodil logging, with custom backend for CLI/TDML
Posted by "stevedlawrence (via GitHub)" <gi...@apache.org>.
stevedlawrence commented on code in PR #954:
URL: https://github.com/apache/daffodil/pull/954#discussion_r1101414107
##########
daffodil-cli/src/conf/.keep:
##########
@@ -0,0 +1,14 @@
+# Licensed to the Apache Software Foundation (ASF) under one or more
Review Comment:
I recall it being a bit of a pain to find the documentation in sbt-native-packager about how to add config files, so I want to keep as much of it around as possible in case we ever need to add some other config file. For example, there are still variables in the CLI sh/bat scripts to locate this directory. For now it's just an empty directory and nothing actually uses it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org