My Application depends on an external jar
<dependency>
<groupId>org.objectweb.joram</groupId>
<artifactId>jftp</artifactId>
<version>1.52</version>
</dependency>
I am mainly interested in using the following package import net.sf.jftp.net.*
But looks like this jar also exposes certain classes in org.apache.log4j package, causing the following exception on deploying application war file to tomcat
java.lang.SecurityException: class "org.apache.log4j.PropertyConfigurator"'s signer information does not match signer information of other classes in the same package
Is there any way i can avoid error?
First you can use
mvn dependency:tree
to see exactly which dependencies are loaded by jftp. Then, exclude the ones you don't want like this:
<dependency>
<groupId>org.objectweb.joram</groupId>
<artifactId>jftp</artifactId>
<version>1.52</version>
<exclusions>
<exclusion> <!-- declare the exclusion here -->
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
</exclusion>
</exclusions>
</dependency>
Related
I have a web application created using spring boot. I have added jasper report, iText and bouncycastle maven dependency. Jasper and iText both contain bouncycastle libraries and now because of this the web application is not working correctly.
Error is: java.security.NoSuchProviderException: JCE cannot authenticate the provider BC. Note that I already added this code: Security.addProvider(new BouncyCastleProvider());
This perfectly works using spring boot embedded tomcat but not when exporting to a war file running on a wildfly server.
Here is how I declare the pom.
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcpkix-jdk15on</artifactId>
<version>1.58</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.itextpdf</groupId>
<artifactId>itextpdf</artifactId>
<version>5.5.13</version>
</dependency>
<dependency>
<groupId>net.sf.jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>6.4.0</version>
<exclusions>
<exclusion>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk14</artifactId>
</exclusion>
<exclusion>
<groupId>org.bouncycastle</groupId>
<artifactId>bcmail-jdk14</artifactId>
</exclusion>
</exclusions>
</dependency>
Upon creating war file, this are the list of libraries included:
bcmail-jdk14-138
bcprov-jdk14-138
bcpkix-jdk15on is not being included even I specify it as provided
To quote directly from the Maven docs
provided
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
To paraphrase, it uses the .jar marked as "provided" to compile (and test) your software, but when you package it up, it will not be included in the .war: you are expecting the runtime system to provide a (presumably different) version of those classes.
Try removing changing the scope of that dependency to "compile" to see if that resolves your problem.
I am new to Google App Engine. I am getting this error :
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.commons.logging.LogFactory at
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:282) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:106) at
org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at
org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at ...
I have added slf4j dependencies and excluded commons-logging in spring-context dependency but still getting this error. The app works perfectly fine on my local machine but gives me this error when deployed to the App Engine.
Thanks to this blog , I was able to resolve this issue :
Commons-logging is a dependency of many frameworks, Spring included. On the local server, everything runs fine. In the cloud, Google App Engine infrastructure replaces the commons-logging-1.1.1.jar with a JAR of its own that has a different package structure. In effect, that means you get funny NoClassDefFoundError on org.apache.commons.logging.LogFactory even though you included the JAR as a dependency. The solution is to still include the classes, but to give the JAR another name.
Since I use Maven, I removed the commons-logging dependency from the WAR with the exclusion tag for Spring and MyFaces artifact. Then, I added a dependency on commons-logging:commons-logging-api:1.1:jar with the runtime scope. This jar won’t be replaced.
So you should exclude commons-logging from Spring :
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>${org.springframework.version}</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
Then add a dependency on commons-logging-1.1 with runtime scope:
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging-api</artifactId>
<version>1.1</version>
<scope>runtime</scope>
</dependency>
You are missing a required jar in your /war/WEB-INF/lib/ folder. It's not enough to have it in your classpath.
If you use Eclipse, you should see a warning in the Problems tab. Right click on it, Quick Fix, select " Copy ...". Or add this jar to the /lib folder manually.
I have prepared some util classes.
I planned to make them as jar and distribute it to required projects.
My util classes uses some already existing custom code provided in the form of jar file.
My code is dependent on "MainUtil.jar" whi internally dependends on Java Servlet, Commons IO, Commons Codec and so on.....
My POM dependency looks as below.
<dependency>
<groupId>com.solutions</groupId>
<artifactId>sol-core</artifactId>
<version>2.3</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-security</artifactId>
<version>${cxf.version}</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-policy</artifactId>
<version>${cxf.version}</version>
</dependency>
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk16</artifactId>
<version>1.46</version>
</dependency>
When I package my jar it looks fine.
But when my jar is used in a project where these my util classes are used , I could see a wierd issue.
The commonc-codec jar files are not included in the project package when packaged.
Also code which requies this common-codec is failing.
When I explicitly include the commons-codec dependency, everything works perectly.
My confusion is, why should I explicitly add the codec dependency when I should be resolved by Maven based on the POM of the custom jar files.
And why the issue is happening only with the commons-codec but not with other dependency.
Your code depends on all the other jars. When you create jar for your project the jar file does not contain all the dependent jar classes.
Where ever you are using your jar you have to use other dependent jars. You have not mentioned whether you are using maven there also. If yes then if you have defined dependency then all the dependent jars will be in the classpath.
Issue with you dependency resolving is,
the existing dependency in your project might have some dependency management on this jar. That is the reason, old jar is taking precedence over your custom jar dependency.
Thry adding exclusion in your already existing jar for this common-codec jar.
like
<dependency>
<... Your existing dependency ..>
<exclusions>
<exclusion>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</exclusion>
</exclusions>
</dependency>
Use this command and check how your dependency is being resolved.
mvn dependency:resolve
Then everything should be fine.
I have an OSGi bundle that does some LDAP operations. It uses Apache Shared Directory to do these operations. I'm using Maven Bundle Plugin to build my bundle. For lack of time and resources, I have to go with in pom.xml, which includes Apache Shared Directory and other jars it depends on, in the generated bundle. One of the dependencies is Xerces, followed by Xml apis. When I include these two jars in the bundle, Karaf throws a ClassCastException:
java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl cannot be cast to javax.xml.parsers.DocumentBuilderFactory
Further investigation revealed that the class javax.xml.parsers.DocumentBuilderFactory is being loaded from two jars - Xml-apis.jar that I included in my bundle and the JRE's rt.jar, which is causing the ClassCastException. Since this class is being loaded from rt.jar, I figured I don't need to include Xml-apis.jar in my bundle and removed it. However, now I see the ClassNotFoundException:
Caused by: java.lang.ClassNotFoundException: javax.xml.parsers.DocumentBuilderFactory not found by mybundle.ldap [149]
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:812)[org.apache.felix.framework-3.2.2.jar:]
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:72)[org.apache.felix.framework-3.2.2.jar:]
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1807)[org.apache.felix.framework-3.2.2.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_35]
So, if I include the xml-apis.jar, I get the ClassCastException. If I don't include it, I get the ClassNotFoundException. Is there a way I can resolve this issue? Any help would be appreciated.
Import the package javax.xml.parsers.
have you tried commenting out the line
javax.xml.parsers, \
in the etc/jre.properties file? This should prevent loading of the class from rt.jar.
Problem solved!! (at least for me)
You can find a very good explanation of the problem in this link:
Dealing with "Xerces hell" in Java/Maven?
As you can read, actually, it's a problem of Xerces compatibility. Maybe you don't use Xerces, but probably you are using a library that use Xerces.
The solution in my case was to use an old version of xerces (lucene-xercesImpl) and exclude any reference to xml-apis o xerces:
<properties>
<ver.jena>2.10.1</ver.jena>
<ver.jena-sdb>1.3.6</ver.jena-sdb>
<ver.h2>1.3.173</ver.h2>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-sdb</artifactId>
<version>${ver.jena-sdb}</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-xercesImpl</artifactId>
<version>3.5.0</version>
</dependency>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>apache-jena-libs</artifactId>
<type>pom</type>
<version>${ver.jena}</version>
<exclusions>
<exclusion>
<artifactId>commons-codec</artifactId>
<groupId>commons-codec</groupId>
</exclusion>
<exclusion>
<groupId>org.apache.jena</groupId>
<artifactId>jena-tdb</artifactId>
</exclusion>
</exclusions>
</dependency>
Hope this help!
Will adding a MANIFEST.MF file with Class-Path attribute to META-INF directory inside EAR influence the order of loading of JARs located in APP-INF/lib under WebLogic 8.1?
I don't believe you can control the APP-INF/lib order via ClassPath attribute of MANIFEST.MF.
I've done this a couple different ways, depending on the client.
Add the patch jar to the system classpath for WLS. If you examine domain/bin/setDomainEnv.sh (or .cmd) there should pre, post, patch classpath environment variables. You could try to add your patch jar to the classpath here. This makes it available for all apps, which might not be what your client wants.
Patch somejar.jar & name it somejar-patched.jar. Replace the jar in APP-INF/lib with the "-patched" version.
I thought the class loader read JARs as they're required by your application.
I have two questions for you:
Why are you still using WebLogic 8.1? It's off support now, and the current version is 10.x. You're two versions behind. Is this a legacy app that hasn't migrated yet? You'll get a big boost by upgrading, because you'll be using JDK 5 or 6 with the -server option. I'd recommend it.
Why should you care about the order of loading? It should be immaterial to your app how the container loads and manages the beans.
UPDATE:
That sounds different, almost as if you were having conflicts with server JARs. There's that prefer-web-inf-classes setting for that situation. Is that what you mean?
I agree with duffymo
You shouldn't have to worry about the order of class loading, if this is due to conflicting classes you can always exclude the conflicting classes from Jars using Maven or a similar tool.
For instance this is a very simple example of adding jersey-spring4 jar but I'm excluding its dependencies so I can use a different version of the spring framework library.
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-spring4</artifactId>
<exclusions>
<exclusion>
<artifactId>spring-web</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-aop</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-context</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-beans</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
</exclusions>
</dependency>