Mule studio loads the log4j properties file from ...eclipse\plugins\org.mule.tooling.server.3.3.1_1.3.2.201212121943\mule\tooling\tooling-support-3.3.1.jar instead of the one provided in the project root folder.
The log4j.properties should be located in src/main/resources, and not in the root folder. You can use the log4j.properties file from the jar as a template and change the logging level with log4j.rootCategory=DESIREDLEVEL, console:
# Default log level
log4j.rootCategory=INFO, console
log4j.appender.console=org.apache.log4j.ConsoleAppender
log4j.appender.console.layout=org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern=%-5p %d [%t] %c: %m%n
################################################
# You can set custom log levels per-package here
################################################
# Apache Commons tend to make a lot of noise which can clutter the log.
log4j.logger.org.apache=WARN
# Shuts up some innocuous messages if using the JBPM transport
log4j.logger.org.hibernate.engine.StatefulPersistenceContext.ProxyWarnLog=ERROR
# Reduce startup noise
log4j.logger.org.springframework.beans.factory=WARN
# Mule classes
log4j.logger.org.mule=INFO
# Your custom classes
log4j.logger.com.mycompany=DEBUG
I found an article that helped me resolve this problem in Mule ESB 3.6. This Mulesoft version uses log4j2 and looks for config as below:
When an application is deployed, Mule will look for a config following
a child first pattern like this:
Look for a file called log4j2-test.xml in the application classpath
Look for a file called log4j2.xml in the application classpath
Look for a file called log4j2-test.xml in the domain classpath
Look for a file called log4j2.xml in the domain classpath
Look for a file called log4j2-test.xml in MULE_HOME/conf
Look for a file called log4j2.xml in MULE_HOME/conf
Apply default configuration.
Just put logj2.xml on classpath ie in src/main/resources. It works.
Link to the article:
http://blogs.mulesoft.org/mule-3-6-asynchronous-logging/
Related
I have deployed one war file in JBOSS eap7.4, but all my logs are going to server.log file by default. I have 2 jars in my war file for which I need to log messages in separate files. Please help me.
This is the custom handler I have created in standalone.xml
And this is the module.xml
This is my log4j.xml file to implement logs for 2 jars with their package names
You need to exclude the org.apache.logging.api from your deployment in a jboss-deployment-structure.xml file. Then include both the log4j-api and log4j-core libraries in your deployment if you want to use a log4j2 configuration file. See the JBoss EAP 7.4 documentation for more details.
You need to achieve this using logging profiles. Please refer
https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/6.4/html/administration_and_configuration_guide/sect-logging_profiles
I am deploying my application as an ear archive in wildfly 13. The ear contains a war and an ejb. The ejb is used in different projects. I want to log the information from the war and the ejb into a single file to have the full context what happend in a single logfile.
I managed to log from the war via logback, but the logs from the ejb are not logged via logback.
My current setup:
In my ear-module I have a jboss-deployment-structure.xml in my ear file to exclude the logging subsystem
In my web-module the logback.xml is located in WEB-INF/classes
In my web-module I have the dependencies to logback-classic and slf4j
In my ejb-module I have a dependency to slf4j
Any suggestions?
If you're just logging to a file you could use a logging-profile which would allow you to make runtime changes and not have to redploy your application if you want to make changes to your logging configuration.
Using WildFly Logging
Example Profile Configuration
/subsystem=logging/logging-profile=ear1:add
/subsystem=logging/logging-profile=ear1/pattern-formatter=PATTERN:add(pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n")
/subsystem=logging/logging-profile=ear1/periodic-rotating-file-handler=FILE:add(append=true, suffix=".yyyy-MM-dd", named-formatter=PATTERN, file={relative-to=jboss.server.log.dir, path="ear1.log"})
/subsystem=logging/logging-profile=ear1/root-logger=ROOT:add(level=INFO, handlers=[FILE])
Then you'd just add Logging-Profile: ear1 entry in your EAR's manifest.
Using Logback
If you want to continue using logback you'd need to put the logback and slf4j dependencies in your EAR/lib directory. The trick will be figuring out where to put the logback configuration file. It might work in EAR/META-INF or in the EAR/lib, but I'm not certain. It may even work if you kept it in the WAR/WEB-INF/classes, but you'd need to ensure a logger is accessed in the WAR before one is accessed in the EJB.
You'll also want to ensure you exclude the org.slf4j.api module or the logging subsystem for the EAR and each subdeloyment in your jboss-deployment-structure.xml.
I am migrating an application from Weblogic to JBoss EAP 6.4. The application originally used Log4J and an external logging configuration properties file. From what I understand, using Log4J would require the log4j.xml or log4j.properties file to be packaged inside the EAR and it would prevent us from changing the logging configuration at runtime.
Currently, I am ok with using the JBoss Logging subsystem to do the logging. However, the application has calls like:
Logger rootLogger = Logger.getRootLogger();
What is the equivalent in JBoss Logging, if I needed to get the RootLogger?
You can use log4j essentially as a logging facade. In other words you don't need to change your logging code at all.
If you want to use the logging subsystem for configuration just ensure your deployment does not have a log4j.xml or log4j.properties file as you stated.
If you want to swap out log4j and use JBoss Logging the equivalent for Logger.getRootLogger() would just be Logger.getLogger("").
I have DN 2.x on Eclipse RCP (currently Helios).
I'm having trouble Turning the DN LOG on.
I use log4j.properties, where i define all the DataNucleus Categories LOG levels.
It LOGS fine with the "external" enhancer (i just pass the argument on the "VM Arguments" of the RUN configurations -Dlog4j.configuration=file:"...\log4j.properties"), but can't get the log to work on the main app... tried the same approach with no success.
Anyone using DN with eclipse?
I don't use DN. So I can't address your problem, directly. I can say, in general, if you have an application using Log4j, it will search the classpath for files named log4j.properties and log4j.xml. In your case, try moving your log4j.properties file to a place you are 100% certain is in the classpath (like the root folder of all your packages).
From there, if your logging turns on, then you know your properties file isn't in the classpath. However, if your file is definitely in the classpath, then the culprit is likely something else turning off logging application-wide. Do you see logging at all? If not, then this is likely the problem. At that point you need to figure out which Facade you're using: apache commons or SLF4J. Both have the power to replace the logger implementation with NOOP loggers, which ignore all log requests.
With Commons, you have to check the commons-logging.properties file. With SLF4J, you have to check the project dependencies (usually in a lib directory somewhere), insuring that there isn't a NO-OP jar in the list.
We need to display JBoss log files from within our web application. Is it possible to achieve this without using ServerConfigLocator ? The application must be able to run also with Websphere and we don't want dependencies on specific JARs.
JBoss's defined log directory is held in the jboss.server.log.dir system property. You can resolve that directory to a java.io.File, and read the files inside.
File logDir = new File(System.getProperty("jboss.server.log.dir"));
logDir.list(); // etc etc
You can also get this through ServerConfig.getServerLogDir() (on JBoss 4.x, anyway), but you said you wanted to avoid JAR dependencies.
You could use a custom log implementation. This would give you complete control over the logging behavior.
JBoss uses Log4j as its logging mechanism. WebSphere uses Jakarta Commons Logging, which can be configured to delegate to Log4j if it isn't already the default. If you already use Log4j in your application then I don't expect that this difference will cause you any new problems.