I'm using CAS for single signon solution, My log(log4j version 1.2.15) file completely fills with the Exception(org.jasig.cas.authentication.handler.BadCredentialsAuthenticationException)
Stack trace when User enters invalid login credentials.
Is there a solution to trim the Stack trace in CAS or Java?
I can't use log4j EnhancePatternLayout to achieve this as it requires log4j version 1.2.16
Any suggestions around this problem would be appreciated.
Thanks
I haven't used CAS. However, the way that I've gotten around similar problems in the past is by suppressing log messages from the offending class. For example, if you're using a log4j.properties file, insert this line:
log4j.logger.com.jasig.cas.WhateverClassLogsTheException=OFF
Note that you will need to suppress messages from the class that throws the exception, not the exception class itself. Also, you can also use FATAL or other values to ensure that only log messages that are at or above the given level are logged. See the Log4J docs for more information.
Note that this will suppress all messages from that class, not just the particular log message that produces that exception.
The problem is CAS is passing Exception object to Log4j,so I did comment that line in my overlayed class. BindLdapAuthenticationHandler.java
Related
in my project i am using the logging module and write the logs into a local .log file, in addition i want to pass the same log to another function to document locally the logs with circular queue algorithm.
it is possible to configure the logger to do it?
thanks .
the currnet logging config
logger=logging.getLogger(__name__)
logger.setLevel(logging.DEBUG)
formatter=logging.Formatter("<SOME FORMAT>")
file_handler=logging.FileHandler('logfile.log')
file_handler.setFormatter(formatter)
logger.addHandler(file_handler)
!! UPDATE : SOLVED - #imriqwe answer here https://stackoverflow.com/a/36408692 helped me to figure it.
I think this thread Python logging to multiple handlers, at different log levels? answers your question, it shows how to add multiple handlers, one file handler and one stream handler.
I see different ways to use Structlog and I was wondering what the exact difference is.
Let's say I want to log something using Structlog, you could for example use:
logger.msg("My log message")
But there are other ways to log, like info, debug (as in the standard Python logging library) which give you the possibility to say something about the importance of a message (which you can filter using loglevel):
logger.info("This is an info message")
logger.debug("This is a debug message")
The question is: what is the advantage of using logger.msg as compared to the other ways to log like info and debug? Why would I choose logger.msg?
msg() is a remnant from the original generic BoundLogger that tried to have both stdlib and Twisted log methods (msg() hailing from the Twisted end).
If you use structlog's internal filtering system via structlog.make_filtering_bound_logger(), it's equivalent to the info log level.
You can safely ignore it.
I wonder what the best practices are with using StructuredArguments inside logging calls when using logstash-logback-encoder to log in JSON format.
I want to log some structured arguments in separate fields, but I don't want to format these arguments into the literal string message.
If I write my log lines like this, everything works fine as I want to, but both my IntelliJ IDEA and Sonarqube static code analysis considers this problematic issues:
log.info("Query executed successfully!", StructuredArguments.value("hits", result.getHits()));
(or more concise)
log.info("Query executed successfully!", v("hits", result.getHits()));
IntelliJ warns this on this line:
more arguments provided (1) than placeholders specified (0)
How can I avoid this? Of course I can silence the warnings and add exceptions for them, but I wonder if that is a best practice.
If you don't want to include the data inside the log message, and want to avoid the static analysis warnings, use Markers instead of StructuredArguments:
import net.logstash.logback.marker.Markers;
log.info(Markers.append("hits", result.getHits()), "Query executed successfully!");
See here for more details.
I'm working on a Windows Store app and I'm getting a WinRT error that doesn't really give me any information so I would like to know how to understand these sorts of errors.
Basically I get the error on the following line which is called inside OnPointerPressed:
m_gestureRecognizer->ProcessDownEvent(args->GetCurrentPoint(nullptr));
The error is:
First-chance exception at 0x76F54B32 (KernelBase.dll) in DXAML2.exe: 0x40080201: WinRT originate error (parameters: 0x80070057, 0x00000044, 0x03CEE72C).
This error didn't used to appear, the only thing I've changed is that this line is now wrapped in an if clause which tests if the current pointer's PointerId is the same as one I've stored just using == such as:
if(args->GetCurrentPoint(nullptr)->PointerId == m_UIPointerID)
I have no idea why this has started happening.
So my question is in two parts:
More generally, how do I understand what an error such as the above means?
And does anyone know this error has suddenly started happening now that I check the pointerId?
Thanks for your time.
P.S. I guess another thing that has changed is that there will already be 2 pointers on the screen (the one that gets pushed into this GestureRecognizer) as well as another one, hence the PointerId check.
"How to Decipher such an error"...
For any WinRT originate error, you can take the third address in the parameters list (in your example, 0x03CEE72C), and find a description of your error in the memory window.
While debugging, break when your error is thrown and open the memory window via Debug -> Windows -> Memory -> Memory 1
Copy and paste the address to get your "easy-to-find" error message.
As Raman said - it's good to look up the hex values shown. The first one is the memory location which won't tell you much without the symbols/source, which in this case is reported directly by Windows. Perhaps the public symbols can shed some more light on where the error came from, but the error code lookups are more helpful.
If you Bing for 0x80070057 you will find an MSDN article on Common HRESULT Values which lists
E_INVALIDARG : One or more arguments are not valid : 0x80070057
It doesn't give you all the details of course, so you're off to theorize. Perhaps you can only call args->GetCurrentPoint(nullptr) once and you should store/reuse the value? Maybe gesture recognizer is not configured correctly? Maybe the app window is not visible at the time the exception is thrown or the thread is wrong. Maybe some expected calls to gesture recognizer were missed due to filtering those out with these "if" statements.
I am trying to track down a problem with GWT. I get an error which I want to track down to the source but log4j truncates the stacktrace by indicating something like "... 26 more" hence I cannot determine the exact location for the problem. I tried finding out if there is anyway to prevent that truncation but have been unable to find any option that will accomplish that. Is this truncation a configurable feature?
I am running Tomcat 6.0.31, Spring 3.0 (for backend), GWT 2.1.0.
Thanks
It isn't log4j truncating the stack trace, it's standard Java. And it's actually only making the trace more readable because those lines that were omitted were already output by the 'enclosing' exception. See Throwable javadoc.