[
https://issues.apache.org/jira/browse/MINIFI-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026297#comment-16026297
]
ASF GitHub Bot commented on MINIFI-296:
---------------------------------------
Github user brosander commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/104#discussion_r118705983
--- Diff: libminifi/test/TestBase.h ---
@@ -21,35 +21,104 @@
#include <dirent.h>
#include <cstdio>
#include <cstdlib>
+#include <sstream>
#include "ResourceClaim.h"
#include "catch.hpp"
#include <vector>
-#include "core/logging/LogAppenders.h"
#include "core/logging/Logger.h"
#include "core/Core.h"
#include "properties/Configure.h"
+#include "properties/Properties.h"
+#include "core/logging/LoggerConfiguration.h"
+#include "spdlog/sinks/ostream_sink.h"
+#include "spdlog/sinks/dist_sink.h"
class LogTestController {
public:
- LogTestController(const std::string level = "debug") {
- logging::Logger::getLogger()->setLogLevel(level);
+ static LogTestController& getInstance() {
+ static LogTestController instance;
+ return instance;
}
-
- void enableDebug() {
- logging::Logger::getLogger()->setLogLevel("debug");
+
+ template<typename T>
+ void setDebug() {
+ setLevel<T>(spdlog::level::debug);
--- End diff --
@phrocker the LogTestController class is already coupled to spdlog (for
construction of the sinks, etc) and was where I was trying to isolate spdlog in
context of the tests. I'd removed the parallel level enum logic we had in the
code because it's only needed in tests as far as I can tell.
> More configurable logging
> -------------------------
>
> Key: MINIFI-296
> URL: https://issues.apache.org/jira/browse/MINIFI-296
> Project: Apache NiFi MiNiFi
> Issue Type: Improvement
> Components: C++
> Reporter: marco polo
> Assignee: Bryan Rosander
> Priority: Minor
>
> The logging functionality would be more useful if it could be tuned on a
> per-class basis. This would allow us to set more detailed log levels for a
> place where trouble is suspected while reducing noise from other areas.
> Composable log appenders would allow us to have multiple sinks so that we
> would have a log appender that could "phone home" with information while
> concurrently logging to disk. Using a processor to do the same may be too
> onerous; however, it stands to reason that we may use the processor as the
> delivery mechanism, so we may eventually negate this issue entirely if it is
> decided that we should ship the log itself via a processor.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
