From the documentation I understand that it supports multiple frameworks like log4j, log4jv2 and slf4j. log4j/log4jv2/slf4j are only the API interfaces and the actual logging will be done by the jboss-logmanager classes located in the "org.jboss.log4j.logmanager" module? If that is the case what is the logger implementation used by jboss-logmanager.
Logging in WildFly is configured via the jboss-logmanager. This is an extension of JUL and does not use log4j or any other log manager. The org.jboss.log4j.logmanager module you reference is like a log4j facade in that it replaces the log4j log manager to write to the jboss-logmanager.
WildFly itself uses jboss-logging. This is simply a logging facade like slf4j.
Related
I have an OSGi application (Eclipse plugin) that contains several bundles.
I have a com.domain.dependencies bundle that, as the name suggests, contains dependencies. There is NO code in this bundle. The concept is that all 3rd-party dependencies used by 1+ other bundles are contained in this bundle and made available to other bundles within the plugin. This has always worked for the past decade or so that this plugin has evolved.
The above bundle 'pulls in' log4j - an older log4j version 1.x. So, log4j has always been exposed as an available library to other bundles that use com.domain.dependencies.
Due to the recent security issues with log4j2, a company security directive/edict has stated that all use of log4j or log4j2 must be upgraded to log4j2 v2.16.0
Initially I thought I'd just change the declaration in the build.gradle file for com.domain.dependencies to pull in that newer log4j2 but discovered that log4j2 is split in to 'core' and 'api' jars. OK so I tried to use those instead. I then followed the Apache migration steps for moving from log4j 1.x to 2.x, updated all the code etc.
After the above, compilation fails. None of the other bundles 'see' log4j2 as they saw log4j. A bit of Googling and I see people talk about creating OSGi Fragments. What's a Fragment? I've read a bit about them and feel none the wiser when it comes to my issue.
I should point out that my plugin also has a dedicated bundle com.domain.log, which depends on com.domain.dependencies and it's the com.domain.log bundle that contains the log4j.properties file (which also needs tweaking for log4j2). This logging bundle wrapped log4j (and soon to be log4j2) to expose logging features to the other bundles within the plugin.
So when it comes to using fragments, I am confused. I see some articles on the internet suggest at least 2 bundles are required. I don't know if these have to be new, or if I can re-use my existing arrangement of bundles. I struggle to relate those articles to how things are currently set up in my plugin, but I wish to maintain the idea that com.domain.dependencies supplies dependencies to other bundles and has no code of itself, while also having the com.domain.log continue to expose the same logging functionality to the other bundles that need it.
My instinctive feelings are that com.domain.log which exposes logging functionality to my other bundles, should use log4j-api, while com.domain.dependencies should obtain log4j-core (implementation) and expose it to com.domain.log. However, I can imagine too many different ways to try and set this up, and all will fail unless I am doing it the right way. Basically, I need help from somebody who knows how to in an OSGi environment.
So, how should I wire-in log4j2 to mimic the traditional behaviour/functionality in my OSGi environment?
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("").
In the spring cloud eureka documentation:
The Eureka server is tied to log4j and doesn’t work with logback, so the dependency configuration has to be tweaked compared to a normal Spring Boot app. The spring-cloud-starter-eureka-server does this for you, but if you add logback transitively through another dependency you will need to exclude it manually, e.g. in Maven
From the SLF4J documentation:
The log4j-over-slf4j module will not work when the application calls log4j components that are not present in the bridge. For example, when application code directly references log4j appenders, filters or the PropertyConfigurator, then log4j-over-slf4j would be an insufficient replacement for log4j.
Is this what the eureka server is doing and what prevents us from using log4j-over-slf4j?
In the normal, a logging framework includes an abstraction layer and an implementation, like slf4j-api and slf4j-simple. logback is also an implementation of slf4j. When we use a logger, we use the interface in abstraction layer to do logging. It will find the implementation lib itself.
log4j-over-slf4j means we use interface in log4j, but use the slf4j implementation to do actual logging. If you use logbak as actual logging implementation, it will use log properties of slf4j, which is logbak.xml.
'The Eureka server is tied to log4j' means we use log4j interface, but spring boot add log4j-over-slf4j and logback to use slf4j logging framework.
log4j-over-slf4j module will not work when the application calls log4j components that are not present in the bridge' means you should not use the classes in the log4j implementation lib in your code. Otherwise, you can not use log4j-over-slf4j to use slf4j implementation.
My application has slf4j logging it should use logback binding, when I try to run on jboss it uses default binding for slf4j in jboss. It throws multiple binding error as it finds logback and jboss binding both. Also I am using slf4j1.7.2 with logback 1.0.9 but I receives error saying SLF4J: The requested version 1.6 by your slf4j binding is not compatible with [1.5.5, 1.5.6, 1.5.7, 1.5.8]
Please help me on this
The step by step guide is at:
http://jaitechwriteups.blogspot.com/2010/04/eclipse-logback-plugin-with-jboss-as.html
The key is to have a class-loader isolation defined in your jboss-web.xml (assuming it is for web app)
Other links that may be helpful (I have to put the links as text as I'm not allowed to put more than 2 links in a post)
http://blog.frankel.ch/configuring-maven-to-use-slf4j
http://www.javacodegeeks.com/2012/07/junit-logback-maven-with-spring-3.html
If you are using Maven please remember:
you have to make sure your libraries are not pulling older versions of slf4j by their dependencies, declare it directly if needed
you do not have log4j in your WEB-INF/lib, if some of your libraries depend on log4j or commons-logging declare relevant bridges (see links above or http://www.slf4j.org/faq.html#excludingJCL)
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.