I am using plugins org.seleniumhq.selenium.api_3.4.0 and org.seleniumhq.selenium.remote-driver_3.4.0 which were created from respective jars in my OSGi project. While executing the tests I am getting the below exception.
[NoClassDefFoundError: org/openqa/selenium/logging/LoggingHandler, ClassNotFoundException: org.openqa.selenium.logging.LoggingHandler cannot be found by org.seleniumhq.selenium.remote-driver_3.4.0
Stack Trace:
java.lang.ClassNotFoundException: org.openqa.selenium.logging.LoggingHandler cannot be found by org.seleniumhq.selenium.remote-driver_3.4.0
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:464)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:171)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
As per my analysis, the issue is coming because the package org.openqa.selenium.logging is present in both org.seleniumhq.selenium.api_3.4.0 and org.seleniumhq.selenium.remote-driver_3.4.0 jars and the LoggingHandler class is present in org.seleniumhq.selenium.remote-driver_3.4.0 jar only. While installing the bundles during startup, the org.seleniumhq.selenium.api_3.4.0 is installed first. So while searching for the class at runtime, the class loader could not find the LoggingHandler class in the plugin org.seleniumhq.selenium.api_3.4.0.
Upgrading the version might resolve the issue because the class LoggingHandler is present in higher versions of org.seleniumhq.selenium.api_3.4.0 jar but I cannot upgrade the version because of other dependency issues.
Is there any other way in OSGi/RCP world to specify which plugin to refer while trying to find the class at runtime. One way which is suggested usually is to specify the version of the import package in Manifest.MF file but here the version of both the jars is same.
Related
I'm using org.slf4j:slf4j-api:1.7.30 and ch.qos.logback:logback-classic:1.2.3 in one of my bundles (Maven <packaging>eclipse-plugin) via the project's Target Platform definition (i.e. another Maven project with <packaging>eclipse-target-definition).
The slf4j-api JAR's MANIFEST.MF contains:
...
Import-Package: org.slf4j.impl;version=1.6.0
The logback-classic JAR also contains the package org.slf4j.impl and its MANIFEST.MF contains:
...
Export-Package: ...
....................., org.slf4j.impl;versi
on="1.7.25";uses:="org.slf4j,org.slf4j.spi"
...
If I add:
Import-Package: ...
...
org.slf4j,
ch.qos.logback.classic,
org.slf4j.impl
to my bundle's MANIFEST.MF` only the first two are resolved. For the latter Eclipse shows the error:
Bundle 'ch.qos.logback.slf4j' exporting package 'org.slf4j.impl' is unresolved
and the ch.qos.logback.classic_1.2.3.v20200428-2012.jar in my bundle's Plugin-Dependencies folder shows only ch.qos.logback.classic package and sub-packages thereof.
Major question:
Why is org.slf4j.impl not considered exported and hence cannot be resolved?
Minor questions:
Where does the Bundle-SymbolicName in the error message come from?
Where does the qualifier v20200428-2012 of logback-classic's JAR in the Target Platform definition come from? It's MANIFEST.MF doesn't contain this, but just Bundle-Version: 1.2.3.
Why does slf4j-api import org.slf4j.impl? Shouldn't rely an implementation on an API and not vice versa?
UPDATE
I found answers to 2. and 3. (not the first that this happens while writing an SO question :): It's from Eclipse itself: https://ftp.fau.de/eclipse/releases/2021-03/202103171000/plugins/
And this also leads to an answer for 1.: I'm actually not using the orignal slf4j and logback JARs but those from Eclipse and ch.qos.logback.slf4j's MANIFEST.MF contains:
...
Export-Package: org.slf4j.impl;x-internal:=true;version="1.7.30";uses:
="org.slf4j,org.slf4j.spi"
...
So 5. How to get the package org.slf4j.impl exported/imported nevertheless?
I have a maven web app project, where I use JodaTime. JodaTime is not directly referenced in my maven project, but is a part of a transitive dependency. In other words, my web app war, has another project of mine as a direct dependency, and that jar contains JodaTime.
I am getting an error after executing these two lines. It compiles fine though.
DateTime firstDate = new DateTime();
firstDate = firstDate.withYear(2016);
And here is my error:
java.lang.NoSuchMethodError: org.joda.time.DateTime.withYear(I)Lorg/joda/time/DateTime;
I know that these kinds of errors can happen if I compile and run with different versions of a library, like this answer says, but the withYear() has been around since JodaTime 1.3, since 2006, and I can't see that I could ever have imported a version that old. I've even checked my final war-file, and the only JodaTime library present, is 2.9.2.
The two lines runs fine if I create a main-method snippet, and run it from within the same project in eclipse. They only fail upon compilation into a war file, and running from my weblogic 10.3.2 server.
Does anyone have any idea on how I can proceed to debug this one?
WebLogic 10.3.6 includes this on the classpath:
joda.time_1.2.1.0.jar
This is earlier than the 1.3 that has the missing method.
Your code compiles, which is a good indication that your app's classpath has at least Joda 1.3.
Thus I suspect this is a WebLogic classpath issue. When your app uses libraries that are also on the WebLogic classpath, you need to tell WebLogic which library to use. You do this with the prefer-application-packages element in src/main/webapp/WEB-INF/weblogic.xml.
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app
http://xmlns.oracle.com/weblogic/weblogic-web-app/1.3/weblogic-web-app.xsd">
<context-root>myApp</context-root>
<container-descriptor>
<prefer-application-packages>
<package-name>org.joda.time.*</package-name>
<package-name>org.slf4j.*</package-name>
<package-name>org.slf4j.impl.*</package-name>
<package-name>org.slf4j.spi.*</package-name>
<!-- others here -->
</prefer-application-packages>
</container-descriptor>
<!-- rest of weblogic.xml here -->
</weblogic-web-app>
WebLogic has a classpath analysis tool called wls-cat to help locate these conflicts, described in this blog post. One caveat - do not just copy wls-cat's prefer-application-packages block into your webapp and think you're done - you need to resolve each conflict one by one. Sometimes that means excluding dependencies from your webapp or using scope provided.
I have a class in a Mule application which resides in a jar of a third party library. The library gets included in the lib folder after the project builds so it is definitely in the classpath. The class is then used in a Mule component. The applications deploys successfully in AnyPoint Studio'sembedded server. However, when the Mule component is processing data, Mule complains that it can't find the class.
As soon as the line with the following code snippet is encountered it throws the NoClassDefFoundError.
populator.put(ScanType.MRI,container);
Here is a portion of the stacktrace:
Root Exception stack trace:
java.lang.ClassNotFoundException: com.tcfg.utils.defn.Populator
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at org.mule.module.launcher.FineGrainedControlClassLoader.findClass(FineGrainedControlClassLoader.java:175)
at org.mule.module.launcher.MuleApplicationClassLoader.findClass(MuleApplicationClassLoader.java:134)
at org.mule.module.launcher.FineGrainedControlClassLoader.loadClass(FineGrainedControlClassLoader.java:119)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
I also know that this is the only instance of the class in the whole project when I use a tool to search the entire lib folder for instances of the class. This is definitely not a situation of multiple versions of the class or of other classes existing in one of the jars with a similar name. What could be the cause of this and how can I resolve it?
Even though if you add the jar in lib folder you need to manually add that jar to your class path.So, that it will be available.
They are 2 possibilities here one is there might be a need of OS specific library to be downloaded and configured in Anypoint Stduio in Run configurations like for SAP we need to point it to the DLL which windows will refer to. Giving below an example.
-Djava.library.path=C:\Users\adm-snandu\AnypointStudio\workspace\
For most of the Class Notfound errors you need to make sure the maven dependency is given in the pom.xml which takes care of downloading all the relevant libraries and referring to them during run time.
I have 2 modules: ejb and war, and ear module, that contains them. Modules build successfully, but when I try to deploy ear to glassfish, I recieve this error:
glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=17;_ThreadName=Thread-2;|Exception while deploying the app [EarModule] : Invalid ejb jar [BackEnd-1.0-SNAPSHOT.jar]: it contains zero ejb.
Note:
1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or message-driven bean.
2. EJB3+ entity beans (#Entity) are POJOs and please package them as library jar.
3. If the jar file contains valid EJBs which are annotated with EJB component level annotations (#Stateless, #Stateful, #MessageDriven, #Singleton), please check server.log to see whether the annotations were processed properly.|#]
I really don't know what to do, I've found a lot of questions like mine, but there was no solution.
I understood, what was wrong. The problem was in run configurations, I'm using Intellij Idea and in run configurations there was build and make before run of my ear module. I removed this and after maven install it deployed successfully.
You have to add an EJB into your WAR or EAR file. Just Create a new Class and annotate it with #Stateless
I know this is very build specific and it uses Netbeans instead of the OP's IDE but because I was lead here and this will likely be useful to some users:
I had the following build:
Netbeans Enterprise Application with Maven
Glassfish 4.1
Java EE 7
I had tried migrating from a previous non-maven enterprise application and the clone didn't quite work the way I expected, there was some old ejb jars lying around that I deleted.
I had done quite a few things to fix it:
Ensure theres no ejb jars lying around that shouldn't be there. Ensure that you don't have accidently have the ejb module jar included more than once as this can result in the same error too (Manually deploying the ear and deployment through netbeans sometimes gave me different errors).
I used the #Remote interface on my EJB applications. Now you should not be importing your EJB into your War, you should use the annotations correctly as described https://docs.oracle.com/javaee/7/tutorial/ejb-intro004.htm
(This is more of a note) When you update any of your war or ejb, clean and build them before cleaning and building your ear (sounds funny right?).
If you are using interfaces for your session beans then you should put them in a separate jar, make a new project maven > java application. Do the same thing with your persistence entities. Add these as dependencies to both your ejb and war project.
This doesn't relate to me in particular but you should have at least 1 #stateless (or I think #stateful) annotation in a java class inside your ejb module for it to run (for the module to be considered an ejb).
I likely had to do a few more things that I forgot but if you still run into issues comment below and I'll try to update.
Just try to build & install your project using Maven , and then , deploy it in glassfish ( do not run your project directly from your IDE )
I encountered this problem as well. It occurred when I had imported a new EJB project into my Eclipse workspace. The project didn't have a reference to the Glassfish libraries then, since it was not yet included in the EAR deployment assembly.
Upon saving the Bean file, the IDE automatically imported javax.inject.Singleton instead of javax.ejb.Singleton. This made the code compile without warnings, but throw the same error as in the original post.
For a school assignment I received a Netbeans project using JNDI and JMS with Glassfish (3 open source edition). All the Glassfish libraries this application is using are referenced by absolute path and all the other libraries (in the "lib" folder) are referenced by relative path.
Since my group is working with a version control system the "lib" folder is included in the repository. This works fine because it is a small project. However the Glassfish libraries are problematic as I am a Linux user and the others are Windows users. We have worked around this problem by letting Netbeans take care of the library paths.
The chosen solution 'works' but is not the best solution. I thought Maven would be a better solution.
However the "gf-client" library is giving problems. Whenever I use the Maven "gf-client" the application throw an exception:
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
Both libraries have "3.1.2" as version. The structures of the libraries look identical and both MANIFEST.MF files too. The size and the md5sum of both files however are not equal.
I've tried all "gf-client" libraries I could find in the default Maven repository and none worked. No other library gives me problems.
Was able to resolve it by adding this to my pom.xml:
<dependency>
<groupId>org.glassfish.main.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.1.2</version>
</dependency>
The gf-client jar is referring to classes in other jars. The first class it was missing was probably java.naming.factory.initial. But after fixing this it still needed a bunch of other classes. Quickest way for me was to add the glassfish-embedded-all dependency.