I am trying to follow this advice to debug my Spray routes, i.e. using logRequestResponse. I am using debug logging level. However, no debug messages appear on the console.
Firstly, the logRequestResponse directive takes an implicit LoggingContext parameter. LoggingContext will log to an implicit akka actor system if there is one in scope (see its Scaladoc for what it will do in other cases). There is an implicit actor system in scope in Spray Testkit, so if you are using that, that's probably the one that will be in scope. That loads from the standard locations (application.conf, reference.conf) so if you want to customise the config, you can do
override def testConfig = ...
Wherever you load the config from, it should contain at least
akka {
loglevel = "DEBUG"
}
to make debug logging show up.
Also, check the config file of your underlying slf4j logging implementation (e.g. log4j) to see where the log statements are being written and what are the minimum log levels in that config file, because that also affects the verbosity of the logging.
Related
I can't be able to add console appender using logger.addAppender method with log4j-over-slf4j 1.7.x dependency. Moreover, I am unable to set target of that particular Console Appender(i.e., SYSTEM_OUT/SYSTEM_ERR).
I have initialized a console appender object and tried to push that reference into addAppender method by typecasting that reference to Appender. But in that case I am unable to set Target/WriterLocation(i.e., SYSTEM_OUT/SYSTEM_ERR) for console appender reference. I have used the below code snippet-
ConsoleAppender ca = new ConsoleAppender();
ca.setWriter(new OutputStreamWriter(System.out)); // this line is not compatible with log4j-over-slf4j jar
ca.setLayout(new PatternLayout("%-5p [%t]: %m%n"));
logger.addAppender(ca);
Please help me to sort out this problem.
What you are doing doesn't make a lot of sense. log4j-over-slf4j will route calls like logger.debug(), logger.info(), etc to slf4j and then presumably to some other logging framework to be logged. Your code is trying to manipulate log4j 1 objects which won't be involved in logging since you are routing log events to SLF4J (which is why many of them aren't supported by log4j-over-slf4j).
In order to help you we would know what logging implementation you really want to use.
I use debug strings for debugging Loopback 2.0 application. Loopback documentation says:
The LoopBack framework has a number of built-in debug strings to help
with debugging. Specify a string on the command-line via an
environment variable as follows:
MacOS and Linux
$ DEBUG=<pattern>[,<pattern>...] node .
Is it possible to change patterns dynamically in runtime? Or is it possible to use environment-specific configuration?
Before I get deeper note that this debug logging facility uses visionmedia's debug module which handles almost all of the logic.
Is it possible to change patterns dynamically in runtime?
Well before any module is loaded, safest and best way I believe is to just manipulate the environmental variables:
if (process.env.NODE_ENV === 'development') {
process.env.DEBUG = process.env.DEBUG + ',loopback:*';
}
Another way would be to load debug and use it's .enable method:
require('debug').enable('loopabck:*');
But note that it only works if you do this before Loopback is required since it only allows changes before it's instances are created, which is in this case before loopback is loaded. Another thing is that, there might be multiple debug modules installed depending on the dependencies and your package manager(npm#3, npm#2 and yarn behave differently). debug might be in your node_modules directory, or it might be in loopback each module, node_modules directory. So make sure you require all instances of it and enable, if you want to do it this way.
Now if don't want to do it on the startup, well API doesn't allow changes in the runtime. You can view the discussion regarding this here. Though there are some dirty ways to go around it, but these might possibly break in the future so be careful.
Firstly, there's a module called hot-debug which supposedly makes require('debug').enable work on previously created instances also, but when I tried it, it didn't work perfectly and it was buggy, but it's possible it might work fine for you.
If that doesn't work for you another way is to override require('debug').log method. If this is defined, debug will call this method instead of console.log with the formatted the arguments. You can set DEBUG=* and then filter it yourself:
require('debug').log = function (string) {
if (string.contains('loopback:security')) {
console.log(string);
}
};
This way will be slow in production though as all the debug output will be formatted before being filtered even though nothing might be outputted to console.
Another thing to override the require('debug').init method. This is called everytime a new debug instance is created. Since every debug instance uses an enabled property to check if it's enabled we can toggle that.
const debug = require('debug');
const { init } = debug;
const instances = [];
debug.init = function(debugInstance) {
init(debugInstance);
instances.push(debugInstance);
};
// You can call this function later to enable a given namespace like loopback.security.acl
function enableNamespace(namespace) {
instances.forEach(instance => {
instance.enabled = instance.namespace === namespace;
});
}
Though there's a lot of improvement can be done on this, but you get the idea.
I can change debug namespace dynamically with the hot-debug module.
In my app, I've just created a function for this :
require('hot-debug')
const debug = require('debug')
function forceDebugNamespaces (namespaces) {
debug.enable(namespaces)
}
// Usage
forceDebugNamespaces('*,-express:*,-nodemon:*,-nodemon')
In my case, I have a config file which allow me to set process.env.DEBUG but I needed to find a way to update debug namespaces without restarting my app (the config file is watched for changed by my app).
I want to log in to multiple log files(flume and console). How to set log4j as package level?ie com.mypackage.myclass into flume and other packages into console..
First of all you need to configure log4j to have two named loggers, one that sends to the Console appender, and one that sends to Flume. You can then write use a proxy class for making your logging calls that routes the log4j calls to the different loggers depending on the package the caller is in. You can do this by accessing the stack of the current thread, like so:
public class Logger
{
public static org.apache.log4j.Logger getLogger()
{
// this will get the calling frame, 0=Thread, 1=this, 2=caller
StackTraceElement stackElement = Thread.currentThread().getStackTrace()[2];
if(stackElement.getClassName().startsWith("the.package.that.goes.to.flume"))
{
return org.apache.log4j.Logger.getLogger("Flume");
}
else
{
return org.apache.log4j.Logger.getLogger("Console");
}
}
}
}
The code above is assuming you have named your two loggers 'Flume' and 'Console'.
When ever you make a logging call in your app, use Logger.getLogger() rather than going to log4j directly.
Check this blog post
http://veerasundar.com/blog/2009/07/log4j-tutorial-adding-log4j-logging-to-your-project/
It has a complete PDF for download on how to add log4j to project.
You need to define categories for different packages.Everything is explained in above PDF.
Hope it helps.
I am looking for some simple answers on how to use funktionality from MSBuild in a c# program. The native documentation seems to be completely useless, because I only find information like:
ConsoleLogger.ApplyParameter
Applies a parameter to the logger
This is the prototype of a explanation, that had better never been written. Neither here, nor under the parameters type explanation you find e.g. a link or any examples about what the parameters might be there for, or their names, or where to find that information
The tutorials I find are all about MSBuild as a standalone tool.
At the moment I need to understand, how to get more information about a failed build:
This method just returns true or false.
bool success = project.Build(new string[] { "Build", "Deploy"}, fileLogger);
Also I need understand how to configure the filelogger, and how to use it from project.
Microsoft.Build.Logging.FileLogger fileLogger = new Microsoft.Build.Logging.FileLogger();
For the particular example in your question, ApplyParameter works the same way that the console logger parameters (/clp) work from the command line.
> msbuild /?
...
/consoleloggerparameters:<parameters>
Parameters to console logger. (Short form: /clp)
The available parameters are:
PerformanceSummary--Show time spent in tasks, targets
and projects.
Summary--Show error and warning summary at the end.
NoSummary--Don't show error and warning summary at the
end.
ErrorsOnly--Show only errors.
WarningsOnly--Show only warnings.
NoItemAndPropertyList--Don't show list of items and
properties at the start of each project build.
ShowCommandLine--Show TaskCommandLineEvent messages
ShowTimestamp--Display the Timestamp as a prefix to any
message.
ShowEventId--Show eventId for started events, finished
events, and messages
ForceNoAlign--Does not align the text to the size of
the console buffer
DisableConsoleColor--Use the default console colors
for all logging messages.
DisableMPLogging-- Disable the multiprocessor
logging style of output when running in
non-multiprocessor mode.
EnableMPLogging--Enable the multiprocessor logging
style even when running in non-multiprocessor
mode. This logging style is on by default.
Verbosity--overrides the /verbosity setting for this
logger.
Example:
/consoleloggerparameters:PerformanceSummary;NoSummary;
Verbosity=minimal
So for the example shown in the help,
logger.ApplyParameter("PerformanceSummary", "NoSummary");
logger.ApplyParameter("Verbosity", "minimal");
If you need a high degree of control over a logger you are attaching to the build engine from code, you might want to consider writing your own logger rather than trying to interpret/parse the text output from the stock console logger.
I have select few places in my application where I'd like to always log values. I could simply use Log.Info() and leave it at that, but I'd prefer a solution that can't be disabled by an accidental change to the level configuration. In this case, as long is log4net is not disabled, I want these log statements to fire.
What's the best approach?
Just looking at some information it looks like one option is to create a custom level with a value set above Emergency, but I don't know if that's a brutally awful hack with side effects I'm not realizing or a legitimate option. I couldn't find any clear guidance in the documentation.
I am not a log4net expert, but something like this might do what you want:
This code will get a named logger from the LogManager and will programmatically set its level to "ALL". If you retrieve this logger later in your code, it will always log, even if the log level is set to OFF in the config file.
To test, set the root log level to "OFF" in the config file, then use the code below:
log4net.ILog log = log4net.LogManager.GetLogger("abc");
log.Info("this won't log because root logger is OFF");
//Reset the level
log4net.Repository.Hierarchy.Logger l = (log4net.Repository.Hierarchy.Logger)log.Logger;
l.Level = l.Hierarchy.LevelMap["ALL"];
//Try to log again
log.Info("this will log because we just reset abc's level to ALL");
I tested it and it does seem to work.
I found this information here and here.