I feel this should be easier, or I am missing something obvious.
I am trying to use our custom JUL logging library with Jetty. No matter where I put the JAR file for the custom logger, it is not found. I have tried the usual suspects; /lib/, /lib/ext/, /WEB-INF/lib/ and even manually added it to the classpath.
2011-06-29 15:27:34.518::INFO: Started SelectChannelConnector#0.0.0.0:8080
Can't load log handler "net.aw20.logshot.client.LogShotHandler"
java.lang.ClassNotFoundException: net.aw20.logshot.client.LogShotHandler
java.lang.ClassNotFoundException: net.aw20.logshot.client.LogShotHandler
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
I am starting up Jetty using "-jar start.jar" technique. Searching around, I have spotted a couple of threads that talk about this problem, but with no resolution. Or if there was, they didn't answer with their solution.
Can anyone help on this front?
Thanks
If you start a Java application with "-jar", the normal classpath-arguments are not used any more. What you can do instead is to list the .jar file in a META-INF/MANIFEST.MF file. I.e. I have the following in one of my jar-files:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 20.6-b01 (Sun Microsystems Inc.)
Built-By: user1
Bundle-Vendor: myCompany
Bundle-Version: 1.0.0.1
Implementation-Version: 1.0.0.1
Class-Path: commons.jar lib/hibernate3.jar
and this way the jars are available as part of the Classpath.
Related
This question already has answers here:
How do I fix a NoSuchMethodError?
(33 answers)
Closed 5 years ago.
I am currently working on a project where we have the log4j-over-slf4j.jar file. In all of the environment, this jar was working. But all of a sudden I have a WebSphere application server.
Our product works on tomcat server and all of the sudden our application was not able to create any logs whereas it was creating in another environment. If I try to remove that jar from the project then I am able to generate logs.
But I am not able to identify why should i do it only specific to this particular environment.
Or what should i do in order to identify the class loader information at server runtime to identify which class is loaded or which method is loaded?
My jdk version is: "1.7.0_71"
My application contains these libraries:
antlr-2.7.7.jar
aopalliance-1.0.jar
asm-1.5.3.jar
asm-attrs-1.5.3.jar
axiom-api-1.2.12.jar
axiom-impl-1.2.12.jar
axis2-1.6.2.jar
axis2-kernel-1.6.1.jar
axis2-transport-http-1.6.1.jar
axis2-transport-local-1.6.1.jar
c3p0-0.9.2.1.jar
cglib-2.1_3.jar
com.ibm.jbatch-tck-spi-1.0.jar
commons-codec-1.6.jar
commons-collections-3.1.jar
commons-fileupload-1.2.jar
commons-httpclient-3.1.jar
commons-logging-1.1.3.jar
dom4j-1.6.1.jar
ehcache-1.2.3.jar
geronimo-activation_1.1_spec-1.0.2.jar
geronimo-javamail_1.4_spec-1.6.jar
geronimo-jta_1.1_spec-1.1.jar
geronimo-stax-api_1.0_spec-1.0.1.jar
geronimo-ws-metadata_2.0_spec-1.1.2.jar
hibernate-3.2.4.ga.jar
hibernate-annotations-3.3.0.ga.jar
hibernate-commons-annotations-3.1.0.GA.jar
hibernate-core-3.3.0.CR2.jar
hibernate-ehcache-3.3.0.CR2.jar
hibernate-entitymanager-3.3.1.ga.jar
hibernate-jpa-2.0-api-1.0.0.Final.jar
hibernate-validator-3.1.0.CR2.jar
httpcore-4.0.jar
javaetmoi-spring4-vfs2-support-1.4.0.jar
javassist-3.18.1-GA.jar
javassist-3.3.GA.jar
javax.batch-api-1.0.jar
javax.servlet-api-3.0.1.jar
jaxen-1.1.1.jar
jboss-common-core-2.0.4.GA.jar
jboss-logging-3.3.0.Final.jar
jettison-1.2.jar
jsr311-api-1.0.jar
jta-1.1.jar
log4j-1.2.17.jar
log4j-api-2.0.jar
logkit-1.0.1.jar
mchange-commons-java-0.2.3.4.jar
neethi-3.0.1.jar
oracle-ojdbc6-11.2.0.3.0.jar
persistence-api-1.0.jar
poi-3.9.jar
slf4j-api-1.7.11.jar
slf4j-simple-1.6.4.jar
spring-aop-3.2.13.RELEASE.jar
spring-batch-core-3.0.1.RELEASE.jar
spring-batch-infrastructure-3.0.1.RELEASE.jar
spring-beans-3.2.13.RELEASE.jar
spring-context-3.2.13.RELEASE.jar
spring-core-3.2.13.RELEASE.jar
spring-expression-3.2.13.RELEASE.jar
spring-jdbc-3.2.13.RELEASE.jar
spring-orm-3.2.13.RELEASE.jar
spring-retry-1.0.3.RELEASE.jar
spring-tx-3.2.13.RELEASE.jar
spring-web-4.0.3.RELEASE.jar
stax-api-1.0.1.jar
woden-api-1.0M9.jar
woden-impl-commons-1.0M9.jar
woden-impl-dom-1.0M9.jar
wsdl4j-1.6.2.jar
wstx-asl-3.2.9.jar
xmlbeans-2.5.0.jar
xmlpull-1.1.3.1.jar
XmlSchema-1.4.7.jar
xpp3_min-1.1.4c.jar
xstream-1.4.7.jar
My tomcat lib directory contains:
annotations-api.jar
catalina-ant.jar
catalina-ha.jar
catalina.jar
catalina-storeconfig.jar
catalina-tribes.jar
ecj-4.5.jar
el-api.jar
jasper-el.jar
jasper.jar
jsp-api.jar
ojdbc6-11.2.0.3.jar
servlet-api.jar
sqljdbc4-11.1.0.7.0.jar
tomcat-api.jar
tomcat-coyote.jar
tomcat-dbcp.jar
tomcat-i18n-es.jar
tomcat-i18n-fr.jar
tomcat-i18n-ja.jar
tomcat-jdbc.jar
tomcat-jni.jar
tomcat-juli.jar
tomcat-util.jar
tomcat-util-scan.jar
tomcat-websocket.jar
websocket-api.jar
NoSuchMethod error happens when your application tries to call a method on a previous version of a class which is not available on the newer version of the class. Bascically this can caused by a version conflict when upgrdading/downgrading or moving into a new environment.
See
https://docs.oracle.com/javase/9/docs/api/java/lang/NoSuchMethodError.html
An indepth description is here.
Docker Image of Jersey Web Application
Checking application libs vs server provided libs wont be a use in here. What matters is what libs/classes are loaded by the JVM classloaders at runtime.
Analyse what are loaded class via java.class.path system property https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html
System.getProperty("java.class.path");
Then compare them with your tomcat version provided jars.
Not sure about the precise environment, but I'm almost sure you're getting an unexpected version of some of the libraries classloaded. If the problem occurs after switching from Tomcat to WebSphere (or the other way around) chances are they either have different versions of something slf4-related (or one of them has a library that the other one is missing). Most of the time java's -verbose:class option should be usable for digging out what gets classloaded from where
You get this type of error, when your code was compiled with a different version of code, than your environment is providing.
public class A{
public void a(){
}
}
//newer version of module
public class AVariant{
public void a(String b){
}
}
I'm not that familiar with WebSphere, but the issue here is that WebSphere uses an older/newer or version of logging framework, that is not compatible the version you are compiling your application. You need to resolve this dependency conflict.
This guide may help you with that:
https://www.slf4j.org/legacy.html
Thanks in advance for any help.
What I want to achieve is project version (Implementation-Version) is printed in a class when it is initiated so that I can trace the version from log file.
I build a JAR file containing the following classes:
com.company.core.common.ClassA
com.company.core.security.ClassB
com.company.core.sql.ClassC
In constructor of com.company.core.sql.ClassC, I want to call System.out.println() to print out the Implementation-Version stored in META-INF/MANIFEST.MF file by calling this.class.getPackage().getImplementationVersion(), but it is getting null value when the class is initiated via Maven test class.
My MANIFEST.MF file contains the following details:
Manifest-Version: 1.0
Implementation-Title: Company Core Library
Implementation-Version: 1.0
Archiver-Version: Plexus Archiver
Built-By: simon
Implementation-Vendor-Id: com.company.core
Build-Time: 2017-02-18T15:07:33Z
Class-Path: lib/sqljdbc42-4.2.jar lib/log4j-api-2.7.jar lib/log4j-core
-2.7.jar lib/json-20160810.jar lib/junit-4.12.jar lib/hamcrest-core-1
.3.jar
Created-By: Apache Maven 3.3.9
Build-Jdk: 1.8.0_102
Implementation-Vendor: Company
Name: com/company/core/
Implementation-Vendor-Id: com.company.core
Implementation-Title: Company Core Library
Implementation-Version: 1.0
Implementation-Vendor: Company
Would I be able to get the Implementation-Version in Maven test class?
If yes, what have I missed out here?
Thanks.
Regards,
Simon.
Within the development environment all class files are found in a named folder target (e.g. within Eclipse). The package path is represented as a directory structure. For a directory structure the existance of a Manifest is not defined. Therefore the dedicated class loader will ignore all requests for a Manifest. This is the reason the call returns null.
Running in the productive environment your product is packed within a jar-file. In this case it is defined, that there is a Manifest-file. The jar file class loader knows about the manifest file and will display version information correctly.
We helped us, by providing a default of "Implementation Version" if the version is retrieved within the development environment.
Today I started experimenting with JxBrowser. Starting the sample with the public static main worked as expected (and it could find the license.jar).
I added a button to a view to start the sample:
btnStart.addSelectionListener(new SelectionAdapter() {
#Override
public void widgetSelected(SelectionEvent e) {
new JxBrowserJavaFXSWT();
}
});
Now I'm receiving:
Caused by: java.lang.RuntimeException: JxBrowser license check failed: No valid license found.
Which is actually odd because it's added the classpath. I tried adding a new Plugin-Project (which is loaded fine) and add the license.jar to its classpath: not working.
I tried to add it to the manifest.mf, build.properties
manifest.mf
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: License
Bundle-SymbolicName: com.teamdev.jxbrowser.license
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.teamdev.jxbrowser.license.Activator
Bundle-Vendor: TEAMDEV
Require-Bundle: org.eclipse.core.runtime
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Bundle-ActivationPolicy: lazy
build.properties
source.. = src/
output.. = bin/
bin.includes = META-INF/,\
.,\
license.jar
src.includes = license.jar
jars.extra.classpath = license.jar
Question: is there a way to add the license.jar to my rcp project and/or what am I missing?
P.S.: if informations are missing to help me solve this I'll gladly add more code, etc
I received the same error, and I have a solution.
Just create a new mail ID and send a request to get a license of JX Browser using that new account, and get it and Download.
Then add that license.jar file in your project. It worked.
You probably need the license.jar in the main plugin class path - the 'Bundle-Classpath'.
Open the MANIFEST.MF editor, switch to the Runtime tab and add the license.jar to the Classpath section (you should also still have the . entry). The Bundle-Classpath should end up looking like:
Bundle-ClassPath: .,
library.jar
I can't give you a perfect answer but I can give you a hint.
First you can extract the licence.jar file to change the extension from .jar to .zip.
Then you can see the following file:
Product: JxBrowser
Version: 6.x
Licensed to:
License type: Evaluation
License info: Single-user license
Expiration date: 22-03-2099
Support expiration date: 22-03-2099
Generation date: 20-02-2017
Platforms: mac/x64;win32/x64;linux/x64;mac/x86;linux/x86;win32/x86;mac/ppc
Company name: NO COMPANY
SigB: jpg317l89241ihodylpum17e2gnk1ufx7bsql1dboldc25pp941s7ksw0wph
SigA: mdluetwphf1vcbl2yzs3ks5c4417pexopgnmap146g8ggk4r4e9ucrzmf1xo
You have to change the values of SigB and SigA.
I tried it, after changing date, but it does not work.
So, let's see, I have three bundles: Provider interface, Provider implementation and Client.
Everything is running smoothly on Eclipse, but when I export the bundles and run em, the following error appears when I try to retrieve the Provider Service:
java.lang.NoClassDefFoundError: provider/providerinterface/ProviderService
The interface is exporting his package, so there should be no errors with that. Alongside, Client is also importing the providerInterface package in its manifest.
The .jar of the Provider interface bundle does have the ProviderService class inside, so there are no error exporting either.
Provider Interface's manifest:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: IMA_Provider
Bundle-SymbolicName: IMA_Provider
Bundle-Version: 1.0.0
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Export-Package: provider.providerinterface
Client's manifest:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: MAClient
Bundle-SymbolicName: MA_Client
Bundle-Version: 1.0.0
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Import-Package: provider.providerinterface,
org.osgi.framework;version="1.3.0",
org.osgi.util.tracker;version="1.4.2"
Provider and Client are just symbolic names, the "Client" bundle imports and uses a lot of other classes from many other bundles with no errors whatsoever. Anyway, I'm getting stuck with this one, and I can't find any reason.
Any help?
Usually there is something wrong with the build.properties file, causing the bundles to miss the actual class files. This does not matter when running directly from Eclipse, but it does matter when you export the bundles using PDE.
Things to check:
Are the classfiles really in the bundles? When checking the bundle, you should have at least at toplevel a provider/ folder and a META-INF/ folder
the build.properties file should look something like:
output.. = bin/
source.. = src/
bin.includes = META-INF/,.
Good luck, Frank
I was finally able to solve this.
There were no issues with the Manifest files or the build.properties, this was a constructor problem.
The MA_Provider implementation was lacking a void constructor; Once I added this
public ProviderImpl(){}
on the implementation class of the ProviderInterface, the OSGi bundles were able to retrieve the service.
I'm running into the following error when attempting to initialize a JMS connection between a servlet on Tomcat and a local ActiveMQ instace.
java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.format(Ljava/lang/String;Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple;
at org.slf4j.impl.Log4jLoggerAdapter.warn(Log4jLoggerAdapter.java:420)
at org.apache.activemq.transport.tcp.TcpTransportFactory.createTransport(TcpTransportFactory.java:132)
at org.apache.activemq.transport.TransportFactory.doConnect(TransportFactory.java:141)
at org.apache.activemq.transport.TransportFactory.doConnect(TransportFactory.java:51)
at org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:80)
at org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:243)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:258)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:230)
at org.apache.activemq.ActiveMQConnectionFactory.createTopicConnection(ActiveMQConnectionFactory.java:208) ...
I believe all my dependencies are in order. Other threads have suggested it's a problem with mismatched slf4j jar libraries. Here is my lib directory.
root#TestDebS:/usr/local/jakarta-tomcat-4.1.24/webapps/examples/WEB-INF# ls lib/
activemq-all-5.5.1.jar exolabcore-0.3.5.jar jndi_1.2.1.jar openjms-0.7.5.jar slf4j-api-1.6.4.jar
classes12.zip exolabcore-0.3.7.jar log4j-1.2.14.jar openjms-0.7.6.1.jar slf4j-log4j12-1.6.4.jar
comm.jar javax.comm.properties log4j-1.2.8.jar openjms-0.7.6.jar xercesImpl.jar
commons-logging-api.jar jms_1.0.2a.jar servlet.jar
Both [tomcat root]/common/lib and [tomcat root]/shared/lib have nothing noteworthy in them. Anyone have any ideas? Thanks in advance for any help you can give!
You have multiple versions of multiple libraries in your WEB-INF/lib; this is a bad idea as it can lead to mixing-and-matching of the different versions depending on which versions contain specific signatures.
Also, you must not deploy your own servlet.jar if that's the servlet API. The errors this causes are often non-obvious. May not solve this problem, but it will certainly stop others from occurring.