We Keep Coding

java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory in OSGi

I'm trying to get the library BioJava to work inside an OSGi context.
To get the JAR into the OSGi context, I'm using the Maven plugin p2-maven-plugin, which generates a file Manifest.MF, and the part relevant to the exception I'm facing is:
Bundle-SymbolicName: org.biojava.core
Bundle-Version: 5.3.0
Import-Package: [snip],
org.slf4j;resolution:=optional,
[snap]
Which looks okay to me. However when I access a class that uses slf4j I get the titular exception:
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.biojava.nbio.core.sequence.template.AbstractCompoundSet.<clinit>(AbstractCompoundSet.java:40)
at org.biojava.nbio.core.sequence.io.ABITrace.getSequence(ABITrace.java:179)
Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory cannot be found by org.biojava.core_5.3.0
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:511)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:414)
Now it's easy to find this exception everywhere, because a lot of people have tried (and failed) to install slf4j. I checked sites like the documentation or the SO question ClassNotFoundException: org.slf4j.LoggerFactory and hence tried to add the following bundles:
slf4j-simple
slf4j-log4j12 (plus the log4j dependencies)
pax-logging-log4j2
However neither worked. Maybe the OSGi container is having problems, but slf4j JARs have the bundle information with the export packages out of the box, so I'm assuming these work. And the BioJava JAR has an import package, so I have no idea why it wouldn't be able to find the class.
Oh, I checked, the LoggerFactory is present in slf4j-api, so it's not that, either.
I also tried different start levels and autostart for the implementations. And I rebundled the JAR without the optional dependency, but I keep having problems because now the MD5 hash is broken.
Has anybody managed to get slf4j to work in OSGi? Or failing that, is there any way to replace that stupid dependency with some kind of Java proxy so I will not need the broken dependency anymore?

resolution:=optional means that when the bundle resolves, it will either get access to the package or not. The framework is permitted to resolve the bundle without access to the package. If the bundle needs access to the package, why make resolution of the package optional?

WFLYEE0040: A component named '...' is already defined in this module

I get this error in a Java maven project. The weird thing is, it doesn't appear on every machine so I assume it has something to do with a configuration issue.
The class RoleKeyCacheImpl is a #Startup #Singleton:
#Startup
#Singleton
public class RoleKeyCacheImpl implements RoleKeyCache { ... }
That's the error Wildfly triggers when deploying the service.
Caused by: java.lang.IllegalArgumentException: WFLYEE0040: A component
named 'RoleKeyCacheImpl' is already defined in this module at
org.jboss.as.ee.component.EEModuleDescription.addComponent(EEModuleDescription.java:167)
at
org.jboss.as.ejb3.deployment.processors.EJBComponentDescriptionFactory.addComponent(EJBComponentDescriptionFactory.java:58)
I've tried:
installing a new Wildfly (V10, V13) on the same machine -> doesn't help
installing a completely new Eclipse on this machine -> doesn't help
cleaning & rebuilding all related projects
making sure the deployments-folder is empty and doesn't contain old versions of the same WAR
read the related question here which also didn't help (they use Spring): A component named 'XXX' is already defined in this module in JBoss 7.1.1
read and tried this q&a: Wrong dependencies with EJB in JBoss Wildfly (server-clean) -> doesn't help
deleted and rebuilt the local maven rep (".m2") -> no effect
checking out the same source on another computer -> does work on one machine, on another it gives the same error
I have absolutely no clue what the issue is or even could be. On one machine, we check it out and it runs without errors. On others, the exact same error happens.
Does anybody have an idea?

I had this same issue multiple times with EAP 7.1 and now again with WildFly 21.0.0. I know by experience this is an issue caused by Eclipse who tries to deploy automatically to a configured WildFly instance. During the deployment (or undeployment) some concurrent file issue arises and files who should be removed, are still on the filesystem, causing this error that a component is already defined.
In fact it is not already defined, it is just WildFly that is confused because it finds in his temporary directories some old files which shouldn't be there and reference your exact same component.
Solution: remove in the WildFly standalone directory the content in the 'deployments' directory and the 'tmp' directory. Rest assured, all what is there is okay to remove safely. Reboot and the error message will be gone ;-)

You should pay attention to not have two #Stateless EJB annotations on top of two classes with the same name - in the same module.
You may differentiate them by using the name attribute in the annotation and put different values in each class

Looks like the class already exists. Check if it does...you may have to rewrite that part of EEModuleDescription to use its own private methods (which would be what you would write) rather than overriding methods in RoleKeyCacheImpl. If the class actually does not exist then right-click on the project -> Maven 2 Tools -> Generate Eclipse Artifacts (Check for Updates). That will regenerate all of the dependencies that the project uses. Also please be sure that you have not added any new projects to the classpath by mistake as that may also cause this error.

I just ran into this today when a colleague added a maven dependency.
Turns out this dependency was a jar with a nasty classpath entry or "../" in the manifest.
I edited the jar's manifest.mf that was cached in my local maven repository using 7-zip and removed the "../" classpath entry.
Then re-packaged my war file (maven clean install) and bingo, it works!
In my case it was caused by org.libreoffice jurt version 5.4.2 (but other versions I checked also have the classpath nastiness).
Unfortunately I was lucky we pinpointed it to a dependency, YMMV!

Remove xercesImpl-2.8.1.jar from the application

Per the recommendation from here: WAS 8.5: java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl incompatible with javax.xml.parsers.SAXParserFactory, I've looked through all the jars and cannot find xercesImpl-2.8.1.jar. I did remove crimson_1.1.1.jar from my project but that did not alter the error (java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl incompatible with javax.xml.parsers.SAXParserFactory). I looked for the method in question (SAXParserFactoryImpl) and found it here: C:\Program Files\IBM\IBMIMShared\plugins\org.apache.xerces_2.9.0.v200805270400.jar. Since this jar is part of the Websphere installation, how can I remove it? Or does it need to be updated with a newer version that resolves this incompatibility?

Ok, I found the solution. With the goal of replacing crimson_1.1.1.jar, I looked for other jars (on my machine) having the class SAXParserFactoryimpl. I found it in several jars, two in particular: xercesimpl-2.8.0 and xercesimpl-2.9.1. I ultimately picked xercesimpl-2.8.0.jar because I needed to include another jar in my app, commons-fileupload-1.2.jar. When I downloaded this commons package to include it into my app, it came with xercesimpl-2.8.0.jar. So with that as the connection, I removed all references to crimson_1.1.1.jar and replaced it with xercesimpl-2.8.0.jar in my application. I also had to set my EAR's deployment descriptor (EAR > deployment descriptor > Deployment tab > Application section) to PARENT_FIRST for Classloader mode and APPLICATION for WAR classloader policy. So with the jars swapped and the deployment descriptor modified, the server started up w/o error and no longer got this incompatibility error and my application was finally working!

websphere classloader gives java.lang.LinkageError when loading slf4j LoggerFactory

[I originally posted this on the websphere forums bot didn't see a timely response. I'm re-posting here with slightly more content]
The Problem
I added a jar (call it "Foo.jar") to our enterprise application (i.e. ".ear"), created the manifest entry, etc., and found, to my surprise, that when my EJB instantiated FooClient, websphere threw a java.lang.LinkageError upon org.slf4j.LoggerFactory
I've added classloader debugging to the trace and did not find much. I was hoping to see "where WAS actually found the slf4j class". Here are the entries:
[9/24/14 16:23:01:417 CDT] 00000067 CompoundClass > loadClass org.slf4j.LoggerFactory this=com.ibm.ws.classloader.CompoundClassLoader#5c2687e4[app:yourappServer] Entry
[9/24/14 16:23:01:418 CDT] 00000067 CompoundClass < loadClass org.slf4j.LoggerFactory java.lang.LinkageError: org.slf4j.LoggerFactory Exit
I've checked my was8 directory and found various copies/versions of the slf4j jar.
/plugins
/osgiappbundles/com.ibm.ws.osgi.applications/aries/slf4j-api-1.5.6.jar
/slf4j-api-1.5.6.jar
/profiles/AppSrv01
/installedConnectors/activemq-rar-5.9.1.rar/slf4j-api-1.7.5.jar
/wstemp
/appdepl14769b0c2de/slf4j-api-1.7.5.jar3472682177251273594.tmp
/appdepl14769b0c2de/slf4j-api-1.7.5.jar7922145899030561292.tmp
Another developer told me "you won't be able to use Foo.jar" because we would need to put "Parent_last" and that's not an option for this project currently.
Additional Context
Websphere 8.0.0.7
RAD 9
Questions
java.lang.LinkageError : is this a 'classloader problem' or 'wrong version of class' problem? My experience with "wrong version of class" problems I usually see "NoSuchMethod" errors, not instantiation exceptions.
Any other way around this?
Updates
I read a bit about shared libraries and "isolated classloader" and this seemed the solution. However for some reason, my RAD/Eclipse UI seems broken as it does not 'save' when I associate the shared library with an application or module. It subsequently disappears.
thanks in advance

if you want to use newer library which is already there in websphere parent_last is the way to go
if not, remove the slf4j jar from the app, and use the version that is given by vendor

Check the version of SL4J expected by Foo.jar and the one you are using: they are surely different. Ensure the correct version has precedence in your classpath: you can put it in WEB-INF/lib but also check that you have just one version of it in WEB-INF/lib.
To discover which SL4J jar you are using you can run
java -verbose:class ....
and the JVM will dump out what it's loading, and from where.
You say "I usually see NoSuchMethod errors" instead of LinkageError; in this case the method exists but has some other incompatibility.

Set the JAXB context factory initialization class to be used

I have updated our projects (Java EE based running on Websphere 8.5) to use a new release of a company internal framework (and Ejb 3.x deployment descriptors rather than the 2.x ones). Since then my integration Tests fail with the following exception:
[java.lang.ClassNotFoundException: com.ibm.xml.xlxp2.jaxb.JAXBContextFactory]
I can build the application with the previous framework release and everything works fine.
While debugging i noticed that within the ContextFinder (javax.xml.bind) there are two different behaviours:
Previous Version (Everything works just fine): None of the different places brings up a factory class so the default factory class gets loaded which is com.sun.xml.internal.bind.v2.ContextFactory (defined as String constant within the class).
Upgraded Version (ClassNotFound): There is a resource "META-INF/services/javax.xml.bind.JAXBContext" beeing loaded successfully and the first line read makes the ContextFinder attempt to load "com.ibm.xml.xlxp2.jaxb.JAXBContextFactory" which causes the error.
I now have two questions:
What sort is that resource? Because inside our EAR there is two WARs and none of those two contains a folder services in its
META-INF directory.
Where could that value be from otherwise? Because a filediff showed me no new or changed properties files.
No need to say i am going to read all about the JAXB configuration possibilities but if you have first insights on what could have gone wrong or help me out with that resource (is it a real file i have to look for?) id appreciate a lot. Many Thanks!
EDIT (according to comments Input/Questions):
Out of curiosity, does your framework include JAXB JARs? Did the old version of your framework include jaxb.properties?
Indeed (i am a bit surprised) the framework has a customized eclipselink-2.4.1-.jar inside the EAR that includes both a JAXB implementation and a jaxb.properties file that shows the following entry in both versions (the one that finds the factory as well as in the one that throws the exception):
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory
I think this is has nothing to do with the current issue since the jar stayed exactly the same in both EARs (the one that runs/ the one with the expection)
It's also not clear to me why the old version of the framework was ever selecting the com.sun implementation
There is a class javax.xml.bind.ContextFinder which is responsible for initializing the JAXBContextFactory. This class searches various placess for the existance of a jaxb.properties file or a "javax.xml.bind.JAXBContext" resource. If ALL of those places dont show up which Context Factory to use there is a deault factory loaded which is hardcoded in the class itself:
private static final String PLATFORM_DEFAULT_FACTORY_CLASS = "com.sun.xml.internal.bind.v2.ContextFactory";
Now back to my problem:
Building with the previous version of the framework (and EJB 2.x deployment descriptors) everything works fine). While debugging i can see that there is no configuration found and thatfore above mentioned default factory is loaded.
Building with the new version of the framework (and EJB 3.x deployment descriptors so i can deploy) ONLY A TESTCASE fails but the rest of the functionality works (like i can send requests to our webservice and they dont trigger any errors). While debugging i can see that there is a configuration found. This resource is named "META-INF/services/javax.xml.bind.JAXBContext". Here are the most important lines of how this resource leads to the attempt to load 'com.ibm.xml.xlxp2.jaxb.JAXBContextFactory' which then throws the ClassNotFoundException. This is simplified source of the mentioned javax.xml.bind.ContextFinder class:
URL resourceURL = ClassLoader.getSystemResource("META-INF/services/javax.xml.bind.JAXBContext");
BufferedReader r = new BufferedReader(new InputStreamReader(resourceURL.openStream(), "UTF-8"));
String factoryClassName = r.readLine().trim();
The field factoryClassName now has the value 'com.ibm.xml.xlxp2.jaxb.JAXBContextFactory'
Because this has become a super lager question i will also add a bounty :)
I will work the entire day on this and let you know if there is any news.
Update/ Solution
This question has been solved. The original problem has occured because misconfiguration of complexly build multi model maven projects which one dependency used a updated version of a customized eclipse link jar that contained a definition for a JAXBFactory not available in the component where the error occured. Setting the JAXB context factory in most cases is configured with a jaxb.propertie file or JAXBContext file that contains the same definition. Detailed loading process of the appropriate JAXBContextFactory happens in javax.xml.bind.ContextFinder.
The error has not yet been solved (during the fact over 4 major EE/SE Applications lead to the error) and there is no general answer but that defined JAXBContextFactorys must exist in your classpath (wow what a wonder...) so you either have a that ClassNotFound Error because youre missing resources (well thats the acctual cause) or because you have a wrong JAXBContextFactory defined in any of the above mentioned propertie files which contain a definition according to the below answer.
Very many thanks for your great comments and support, i realy appreciate!

You can include a jaxb.properties file in the same package as your domain model to specify the JAXB (JSR-222) implementation you wish to use. For example it would look like the following to specify EclipseLink MOXy as your JAXB provider.
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory
For More Information
http://blog.bdoughan.com/2011/05/specifying-eclipselink-moxy-as-your.html

Another quick and dirty solution (a workaround, really) that worked for me is to explicitly include a JAXB implementation to the maven build. For example
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.2.7</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.2.7</version>
</dependency>
Note that this adds a somehow unnecessary dependency to your build, as JAXB obviously already is part of each JRE >= version 6.
Most likely this will only work when the WAS classloader is set to parent last.