I have a Mule flow which obtains an oauth token from a service which may throw a fault. However the exception is not caught in the flow even though there is a catch exception strategy at the end. Can someone explain why the exception is not caught? When I post XML via SOAP UI using an invalid token to trigger an exception, the request gets to the flow, but the exception is not caught. Instead I get a stack trace indicating an invalid token. Here is the flow:
<flow name="order-query">
<http:listener config-ref="HTTP_config"
path="order/request" doc:name="HTTP" />
<flow-ref name="oauth-token-service">
<cxf:jaxws-service doc:name="SPOP SOAP"
serviceClass="o.x.p.SpopWS">
<cxf:inInterceptors>
<spring:ref bean="HeaderInInterceptor" />
</cxf:inInterceptors>
<cxf:outInterceptors>
<spring:ref bean="faultOutInterceptor" />
<spring:ref bean="headerOutInterceptor" />
</cxf:outInterceptors>
<cxf:outFaultInterceptors>
<spring:ref bean="OutSoapFaultInterceptor" />
</cxf:outFaultInterceptors>
</cxf:jaxws-service>
<scripting:transformer>
<scripting:script engine="python">
...
</scripting:script>
<scripting:transformer>
<catch-exception-strategy>
<logger level="INFO" message=" Should be handled here #[payload]"/>
</catch-exception-strategy>
</flow>
are you sure the exception is not catched? the default behavior of catch-exception-strategy is to log the catched exception. This is the reason why you see the stack trace in logs.
for mule 3.8 and above: you can disable/enable this behavior either with a checkbox (Log Exceptions):
or in XML (logException=false):
<catch-exception-strategy logException="false" doc:name="Catch Exception Strategy">
<logger level="INFO" doc:name="Logger"/>
</catch-exception-strategy>
for mule 3.7: take a look here: https://stackoverflow.com/a/42181054/804521
I am using mule request response VM and need the rollback messages to be reprocessed by VM in case of some exceptions, say connection issues. However, the rollback exception strategy does not appear to work when I use exchange pattern as request response for VM. The reason I used request response is I need way to know when all my VM messages have been processed and initiate another task after that. I think the behavior is that when there is an exception, the rollback strategy catches the exception and probably commits it. I do not see it trying the redeliver the message back to VM. It does work good when the exchange pattern is one-way.
<flow name="vmtransactionrollbackFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/myvm" doc:name="HTTP"/>
<set-payload value="Dummy list payload" doc:name="Set Payload"/>
<foreach doc:name="For Each">
<vm:outbound-endpoint exchange-pattern="request-response" path="myvm" connector-ref="VM" doc:name="VM">
<vm:transaction action="ALWAYS_BEGIN"/>
</vm:outbound-endpoint>
</foreach>
<logger message="DO SOMETHING ONLY AFTER ALL MESSAGES IN VM ARE PROCESSED" level="INFO" doc:name="Logger"/>
</flow>
<flow name="vmtransactionrollbackFlow1">
<vm:inbound-endpoint exchange-pattern="request-response" path="myvm" connector-ref="VM" doc:name="VM">
<vm:transaction action="BEGIN_OR_JOIN"/>
</vm:inbound-endpoint>
<scripting:component doc:name="Groovy">
<scripting:script engine="Groovy"><![CDATA[throw new java.lang.Exception("Test exception");]]></scripting:script>
</scripting:component>
<rollback-exception-strategy maxRedeliveryAttempts="3" doc:name="Rollback Exception Strategy">
<logger message="Rolling back #[payload]" level="INFO" doc:name="Logger"/>
<on-redelivery-attempts-exceeded>
<logger message="Redelivery exhausted:#[payload]" level="INFO" doc:name="Logger"/>
</on-redelivery-attempts-exceeded>
</rollback-exception-strategy>
</flow>
Yes I ran into a similar problem, when the VM outbound uses a request-response exchange pattern it behaves more like flow-ref with no "queue" involved per say and hence no redelivery mechanism.
So if the VM's are configured as one-way and the flow processing strategy is synchronous (VM inbound flow), then the redelivery does kick in.
To achieve what you want you could use until-successful scope within the vmtransactionrollbackFlow1 flow, especially for the case of intermittent connection losses this is actually the recommended approach. In which you do not need transactions at all.
Do let us know how it goes, and if you found some other work around.
I have a logback configuration that has an appender with a threshold filter:
<appender name="SYSLOG" class="ch.qos.logback.classic.net.SyslogAppender">
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>INFO</level>
</filter>
...
</appender>
This ensures that only info and higher (warn, error) get logged to syslog. However, one of the 3rd party libraries we use is logging a particular event at DEBUG, and I would like to log this event to syslog. The first approach I had in mind was to try remap the log level in the logger, but am not sure if this is possible? Something like:
<logger name="akka.some.Thing" level="DEBUG" logAs="INFO">
<appender-ref ref="SYSLOG" />
</logger>
obviously, the "logAs" parameter doesn't exist, so I can't do that. What would be the best approach to logging akka.some.Thing to the SYSLOG appender while leaving the filter in place for other loggers?
The other approach would be to create a 2nd appender called SYSLOG2 that doesn't have the filter in place and set the specific logger to use that, but was wondering if there was a way to configure logback with just 1 SYSLOG appender...
Thanks,
I know this is an old question - but it is actually possible to do what the OP wants to do with a single SyslogAppender.
If others are searching for an example of how to remap you can take a look at the org.springframework.boot.logging.logback.LevelRemappingAppender class.
With that appender it is possible to both remap what appender is finally used for the log event, and it is also possible to remap the level that is used for the final log event - e.g. by changing a DEBUG level into an INFO level.
Usage example in logback config file (taken from https://github.com/spring-projects/spring-boot/blob/master/spring-boot/src/main/resources/org/springframework/boot/logging/logback/defaults.xml):
<appender name="DEBUG_LEVEL_REMAPPER" class="org.springframework.boot.logging.logback.LevelRemappingAppender">
<!-- Optional: specify the destination logger the event ends up in -->
<destinationLogger>org.springframework.boot</destinationLogger>
<!-- Optional: specify log level remapping -->
<remapLevels>INFO->DEBUG,ERROR->WARN</remapLevels>
</appender>
<logger name="org.thymeleaf" additivity="false">
<appender-ref ref="DEBUG_LEVEL_REMAPPER"/>
</logger>
Note that remapping to a specific destination logger can make it harder to find the source code of the original log event - so use it with care.
What you can do, is writing a second logger + appender with the same output:
<appender name="SYSLOG-2" class="ch.qos.logback.classic.net.SyslogAppender">
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>DEBUG</level>
</filter>
...
</appender>
<logger name="akka.some.Thing" level="DEBUG">
<appender-ref ref="SYSLOG-2" />
</logger>
This will add your specific DEBUG tasks to the same output.
This seems like a carelessness error, but I can't seem to find the cause. Logging with logback/slf4j (most recent version slf4j-api-1.6.1, logback core/classic 0.9.24). Simplest log configuration for testing is:
<configuration>
<appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
<layout class="ch.qos.logback.classic.PatternLayout">
<!-- DONT USE THIS FORMATTER FOR LIVE LOGGING THE %L LINE NUMBER OUTPUTTER IS SLOW -->
<pattern>%le %-1r [%c{1}:%L] %m%n</pattern>
</layout>
</appender>
<root level="DEBUG">
<appender-ref ref="stdout" />
</root>
</configuration>
Every log setup starts with logback's internal status lines:
11:21:27,825 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
11:21:27,826 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] at [file:.../logback-test.xml]
11:21:28,116 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
11:21:28,124 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
11:21:28,129 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [stdout]
11:21:28,180 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [layout] on top of the object stack.
11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - This appender no longer admits a layout as a sub-component, set an encoder instead.
11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - To ensure compatibility, wrapping your layout in LayoutWrappingEncoder.
11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - See also http://logback.qos.ch/codes.html#layoutInsteadOfEncoder for details
11:21:28,207 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
11:21:28,207 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [stdout] to Logger[ROOT]
which is, according to the docs, the format logback uses for default. It then finishes reading the config (which is set up to output a different format) and continues with the properly formatted output. There's a config parameter <configuration debug="false"> which does not affect this.
Anyone know how to shut this off?
If you set the debug attribute of the configuration element to true, you will get all status information to the console. If this is your problem, just set it to false or remove it.
If you have any configuration problems of level WARN or above, you will also get all status information logged to the console (including messages of level INFO). The best solution to this problem is to fix the problem (in your case replace the <layout> element with an <encoder> element).
If you for some reason cannot fix the problem, but want to remove the status-information from the console, you can instead configure an alternative StatusListener. Use the NopStatusListener to completely remove the status-information:
<configuration>
<statusListener class="ch.qos.logback.core.status.NopStatusListener" />
<!-- etc -->
</configuration>
As described in the docs, if warnings or errors occur during the parsing of the configuration file, logback will automatically print status data on the console.
Follow http://logback.qos.ch/codes.html#layoutInsteadOfEncoder i.e.
the link mentioned by logback in its warning message. Once you follow the steps mentioned therein, that is, if you replace <layout> element with <encoder>, logback will stop printing messages on the console.
Ceki answer is correct:
(...)if warnings or errors occur during the parsing of the configuration file, logback will automatically print status data on the console.
Once you get it right, there won't be any pollution in the first lines of your log anymore.
As of March 2015, in Logback 1.1.2, you need to use <encoder> sub-component - <layout> is now deprecated and if use it, error messages will appear. You cannot control this, it´s Logback default behavior.
Some internal classes have been renamed too, and even the examples in their manual page are outdated!
Here is the code snippet from their Errors Code Help page, which has the correct way to config the logger. This fixed the issue completely in my project.
http://logback.qos.ch/codes.html#layoutInsteadOfEncoder
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>testFile.log</file>
...
<encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
<pattern>%msg%n</pattern>
</encoder>
</appender>
I had the same problem i added this line
<!-- Stop output INFO at start -->
<statusListener class="ch.qos.logback.core.status.NopStatusListener" />
in the logback and it succefully worked
I realized Steve found the fix but he didn't mention it on the thread. In case if any other person hit the same issue here is the fix.
Replace "<layout>" elements with "<encoder>..</encoder>"
The culprit is:
<layout class="ch.qos.logback.classic.PatternLayout">
I prefer to use status listener in order to switch off own logback logs:
<configuration>
<statusListener class="ch.qos.logback.core.status.NopStatusListener" />
...
</configuration>
But as was mentioned NopStatusListener also prevents showing warning and errors. So you can write your custom status listener and change log level for it manually:
package com.your.package;
import ch.qos.logback.core.status.OnConsoleStatusListener;
import ch.qos.logback.core.status.Status;
import java.util.List;
public class PrintOnlyWarningLogbackStatusListener extends OnConsoleStatusListener {
private static final int LOG_LEVEL = Status.WARN;
#Override
public void addStatusEvent(Status status) {
if (status.getLevel() == LOG_LEVEL) {
super.addStatusEvent(status);
}
}
#Override
public void start() {
final List<Status> statuses = context.getStatusManager().getCopyOfStatusList();
for (Status status : statuses) {
if (status.getLevel() == LOG_LEVEL) {
super.start();
}
}
}
}
Then use it in your logback.xml file:
<configuration>
<statusListener class="com.your.package.PrintOnlyWarningLogbackStatusListener" />
...
</configuration>
Struggled with the same problem myself i.e. there were a bunch of lines logged right at the beginning which were not related to my code. Here is how I fixed it.
<configuration debug="false">
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<!-- <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level
%logger{36} - %msg%n</pattern> </encoder> -->
<encoder>
<pattern>%d{HH:mm:ss.SSS} %-5level %logger{10} - %msg%n</pattern>
</encoder>
</appender>
<root level="error">
<appender-ref ref="STDOUT" />
</root>
<logger name="fun.n.games" level="DEBUG" />
This is running with the following entry in the pom.xml
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.2.3</version>
</dependency>
This seems to be Fixed in 0.9.29. Just made several tests. No Joran INFO anymore. I guess this is the fixing commit.
I've tried everything and nothing worked for me. My problem was due to multiple logback.xml files in my classpath. This is the common case in multi modular projects.
When there is only one logback.xml file in classpath, there is no ambiguity and the problem is solved.
Using the logback.groovy: statusListener(NopStatusListener) (in the src/test/resources/logback.groovy) works.
(A valid use case is e.g. if working with ANT in Eclipse, using logback logging, groovy classes and unit tests where the unit tests take the src/test/resources/logback.groovy, but will also see the src/main/resources/logback.groovy (or similar) you cannot exclude (if ANT's classpath is said to use the projects classpath).)
Just for people landing here because of the status messages logged by ch.qos.logback.access.tomcat.LogbackValve#LogbackValve (recent versions). Just set the quiet flag:
var v = new LogbackValve();
v.setQuiet(true); // disable status messages!
v.setFilename("logback-access.xml");
See also the documentation for XML configuration.
Is it possible to set the logger from configuration. I have a web app
using a framework. The framework is extensible and has the logger.
When I log, currently, the logger is set to the framework class.
Is it possible that I can configure my web app and set the logger for the web app to
loggerForWebApp and the logger for a console app (which is using the
same framework) to loggerForConsoleApp?
In addition to the root logger (which must always be there) you can have named loggers with their own appender-refs and levels.
For instance, you could have something like this:
<root>
....
</root>
<logger name="loggerForWebApp">
<level value="WARN" />
<appender-ref ... />
</logger>
<logger name="loggerForConsoleApp">
<level value="WARN" />
<appender-ref ... />
</logger>
In code, you would summon these loggers by their name:
var log = LogManager.GetLogger("loggerForWebApp");
Most definitely, and this is one of the great things about log4net: it can log out to a wide range of loggers.
For examples of the appenders, see here. Probably the most common one in use is the RollingFileAppender, but the ConsoleAppender can be very handy for console applications. Alternatively the TraceAppender can write out to the standard .NET trace listeners for further redirection (or display in the debug Output window in Visual Studio).
To create your own, implement IAppender.
details to follow