[
https://issues.apache.org/jira/browse/MINIFI-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16025020#comment-16025020
]
ASF GitHub Bot commented on MINIFI-296:
---------------------------------------
Github user phrocker commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/104#discussion_r118527482
--- 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 --
can we decouple arguments from spdlog? "debug" seems to suffice here and I
believe we had that previously. I think that's probably the best way to
minimize future pain.
> 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)
