2
exception loader constraint violation: when resolving method "org.apache.hadoop.io.IOUtils.cleanup(Lorg/apache/commons/logging/Log;[Ljava/io/Closeable;)V" the class loader (instance of weblogic/utils/classloaders/ChangeAwareClassLoader) of the current class, org/apache/hadoop/hdfs/FileInputStreamCache, and the class loader (instance of weblogic/utils/classloaders/GenericClassLoader) for resolved class, org/apache/hadoop/io/IOUtils, have different Class objects for the type org/apache/commons/logging/Log used in the signature

I get this when using the application, not when deploying the ear. If i understand this wright, i have two classloaders that have two different logging objects? how can i refer them both to one?
EDIT 1
After further investigation, I think this error is due to the fact we are using a common jars library and there is another version of commons there, making them conflict. Is there any way to specify weblogic to use a specific library and not packaging? I would like to investigate this further

diazazar
  • 522
  • 1
  • 5
  • 24
  • What are you using for dependency management for your application? – kaos Aug 05 '14 at 12:06
  • Do you have a dependency to commons-logging in your poms? If yes try scope provided if not set already. – kaos Aug 05 '14 at 20:20

2 Answers2

2

You will have to update your weblogic-application.xml to use the use the prefer-application-package to tell the web logic to use the jar from the web-inf/lib instead of the jar from web logic. refer to the link Weblogic 10.3.5 Overriding Spring Version

<weblogic-application>
    <prefer-application-packages>
       <package-name>org.apache.*</package-name>
       <package-name>org.springframework.*</package-name>
    </prefer-application-packages>
</weblogic-application>
Community
  • 1
  • 1
Biggy_java2
  • 1,931
  • 3
  • 20
  • 21
  • I am using that. The project is using that from the get-go, but i think it's somehow ignored. The error is due to two log implementations,i will inspect that too – diazazar Jul 28 '14 at 09:42
2

You need to check the WEB-INF/lib directory of your WAR files to ensure that they do not contain jars that also exist in the EAR/lib directory.

Web apps will always use the WEB-INF/lib classes before looking for them in the EAR file. However, classes loaded from the EAR will only see the other classes in the EAR. If you have the same (or similar) jar file in both places this will lead to class loading issues such as you describe.

Steve C
  • 18,876
  • 5
  • 34
  • 37
  • Thanks for the reply Steve! What I don't understand is why does it create such problems if the classes loaded form the EAR sees only other classes in the EAR. If EAR sticks with EAR and WAR with WAR, why do I have this issue? – diazazar Aug 04 '14 at 15:13
  • Presumably your WAR file will be loading *some* classes from the EAR, otherwise why have it in there at all. Your web app will inevitably end up with references to classes loaded from the EAR, some of which may reference the EAR version of a class. Mixing this with the WAR version of the class will lead to all kinds of exciting class loading problems – Steve C Aug 04 '14 at 15:25
  • I get it now what you are trying to say. Basically the war loads classes from two places and they don't match. I will try this when i get home – diazazar Aug 04 '14 at 15:32
  • One thing still bugs me: i have both and . If I use this, shouldnt it use the war jar? – diazazar Aug 04 '14 at 15:45
  • I believe that these tags are used to exclude classes that are in the server class path. i.e Classes that come from outside your application. – Steve C Aug 04 '14 at 23:41