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)
Related
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.
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?
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.
Here is my configuration:
We are developing an OSGi application and want to include logging. I decided to use slf4j + logback.
We are using Eclipse as an IDE and Tycho to benefit from the Eclipse IDE like Manifest Editor and so on.
So I have tried the following:
Created a new plugin with the following Manifest.mf:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Createcommand
Bundle-SymbolicName: de.hswt.oms.ws.wsr.createcommand
Bundle-Version: 1.0.0.qualifier
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Import-Package: de.hswt.oms.ws.command.wsr,
de.hswt.oms.ws.ds.core.data.impl,
org.slf4j
Service-Component: OSGI-INF/component.xml
Now when i move to Run -> Run Configurations -> OSGi Framework and select my Bundle and click "Add Required plugins" more than 100 Bundles will be selected and I get a lot of errors and exceptions.
So I came up with a new plugin from existing Jars which include the following three jars:
logback-classic-1.0.7
logback-core-1.0.7
com.springsource.slf4j.api-1.6.1 (I dont believe this is a good idea, but hey...)
If I create a new run configuration manually (not clicking "add required bundles" it works as expected but as far as I click "add required bundles" I come back to the more then 100 Bundles with a lot of errors (some Jetty stuff for example...)
So my Question is: How can I enable logback and slf4j in my OSGi application and use it within eclipse and configure it properly?
If you need more information please feel free to ask.
AFAIK there are some issues in the bundle manifest header in the current official Logback/SLF4J jars. However, you only need the following three jars/bundles. No other are required for the basic functionality.
SLF4J API
Logback Core
Logback Classic
At Eclipse we put the bundles in Orbit for re-use across projects. We apply some modifications to the manifest header that we think are beneficial. For example, we deliver the actual SLF4J binding as a fragment to avoid the circular dependency of the original SLF4J API jar.
Here are the download links to the bundles:
org.slf4j.api
ch.qos.logback.core
ch.qos.logback.classic
ch.qos.logback.slf4j
You may also want:
org.slf4j.ext
org.slf4j.jcl (Commons Logging via SLF4J)
org.slf4j.jul (Java Logging Bridge)
org.slf4j.log4j (LOG4J via SLF4J)
Please note that "Add Required plugins" is not smart enough. It may select too many or too few plug-ins. Sometimes service API is delivered in one bundle but the actual service implementation is delivered in a second bundle. It may not select that bundle.
There is a checkbox saying something like 'Resolve optional imports'. It's on by default, but that pretty much always results in the behaviour you describe, that it wants to add everything.
Switching that off should help. also, PDE tends to add a lot of fragments that are not needed.
All in all, I rarely trust Eclipse with adding the 'right' bundles for runtime. I just use 'validate' and add whatever is needed manually, and check again. It might take a few minutes but figuring out what went wrong when you leave it to PDE can take hours.
Not sure about logback but you may also want to try pax logging. Just install pax logging api and pax logging service and it should work. There is also a documentation how to set it up in eclipse.
If you want it to use with Eclipse Equinox, you could try the Eclipse-BuddyPolicy. This enables one plugin to load all classes from another plugin without importing it explicitly.
This may solve your problem.
Add to your Manifest from the bundle with the jars:
Eclipse-BuddyPolicy: dependent
and to the bundle using the logging
Eclipse-RegisterBuddy: com.other.plugin
see http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html
One of our plugins requires an installed JDK, not just an JRE. We need com.sun.javadoc and friends from tools.jar. I do not think Sun's license will allow redistributing tools.jar (which is not necessary if you already have a JDK anyway).
It also seems there is no way in Eclipse to specify a JDK as a dependency. All answers in the Eclipse newsgroups suggest that end users will have to configure their Eclipse properly first.
Do you know any workaround that will make this dependency obvious to users of our plugin, just by using Eclipse's on-board mechanisms for dependencies? It seems this package is not even valid for Import-Package in the manifest, unlike e.g. com.sun.jdi.
(As a work-around, currently we can only warn on plugin activation that this library is missing.)
Since eclipse offers an OSGi environment, you could refer to the article "Exposing the boot classpath in OSGi", and try using:
a System Packages declaration
a Extension Bundles (Fragment) declaration
or boot delegation
By specifying the JDK packages you need, the OSGI framework will attempt to load them (and fail if there are not here).
By specifying one specific to JDK5 or JDK6, you could even ensure the right version of the JDK.
The OSGi spec allows the Framework (through its system bundle) to export any relevant packages from its parent class loader as system packages using the org.osgi.framework.system.packages property.
As repacking the hosting JDK as a bundle isn't a viable option, one can use this setting to have the system bundle (or the bundle with id 0) export these packages itself.
Most of the OSGi implementations already use this property to export all the public JDK packages (based on the detected JDK version). Below is a snippet from an Equinox configuration file for Java 1.6:
org.osgi.framework.system.packages = \
javax.accessibility,\
javax.activity,\
javax.crypto,\
javax.crypto.interfaces,\
…
org.xml.sax.helpers
Using this property, one can add extra packages that will be loaded and provided by the framework and that can be wired to other bundles.
org.osgi.framework.system.packages = \
javax.accessibility,\
javax.activity,\
…
org.xml.sax.helpers, \
special.parent.package
Note: the simpler solution of specifying Bundle-RequiredExecutionEnvironment is only for the JRE, not the JDK...
That kind of configuration need to be part of the config.ini of the Equinox framework (see this example for Jetty and its config.ini).
In your case, it would be declared in the config.ini of your fragment.