Weblogic Guava issue when deploying application

Question

I'm trying to deploy an application to a weblogic server, and I get the following error.
I have guava.jar in my classpath, I tried with all the latest versions I tried from 10 and up. Can somebody help me out with this?

    <Error> <Console> <BEA-240003> <Administration Console encountered the following error: weblogic.application.ModuleException: [HTTP:101216]Servlet: "action" failed to preload on startup in Web application: "...".
java.lang.NoSuchMethodError: com.google.common.util.concurrent.MoreExecutors.sameThreadExecutor()Lcom/google/common/util/concurrent/ListeningExecutorService;
            at com.google.common.cache.LocalCache.<clinit>(LocalCache.java:155)
            at com.google.common.cache.LocalCache$LocalManualCache.<init>(LocalCache.java:4750)
            at com.google.common.cache.LocalCache$LocalLoadingCache.<init>(LocalCache.java:4858)
            at com.google.common.cache.CacheBuilder.build(CacheBuilder.java:739)
            at com.my.app.servers.UserServer.<clinit>(UserServer.java:42)
            at com.my.app.ActionServlet.setAppProperties(DesActionServlet.java:207)
            at com.my.app.ActionServlet.init(DesActionServlet.java:167)
            at javax.servlet.GenericServlet.init(GenericServlet.java:240)
            at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:299)
            at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubSecurityHelper.java:250)
            at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
            at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
            at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
            at weblogic.servlet.internal.StubSecurityHelper.initServletInstance(StubSecurityHelper.java:94)
            at weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityHelper.java:82)
            at weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLifecycleHelper.java:74)
            at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper.java:60)
            at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper.java:34)
            at weblogic.servlet.internal.ServletStubImpl.initStubLifecycleHelper(ServletStubImpl.java:624)
            at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:565)
            at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServletContext.java:1874)
            at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(WebAppServletContext.java:1848)
            at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1738)
            at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
            at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1704)
            at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
            at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
            at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
            at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
            at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:70)
            at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:212)
            at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:111)
            at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
            at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
            at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
            at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
            at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:70)
            at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:24)
            at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729)
            at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
            at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258)
            at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:48)
            at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
            at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79)
            at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:582)
            at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:148)
            at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:114)
            at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:335)
            at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844)
            at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253)
            at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440)
            at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163)
            at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
            at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)
            at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)
            at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
            at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
            at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)

Caused by: java.lang.NoSuchMethodError: com.google.common.util.concurrent.MoreExecutors.sameThreadExecutor()Lcom/google/common/util/concurrent/ListeningExecutorService;

What puzzles me is that some guava classes are present. Are you using ProGuard ? What is you build system ? — Pierre-Henri, Nov 13 '12 at 15:01
UPDATE!! in the end i got the problem with the solution from @Chris Povirk but i got it solved [here](http://stackoverflow.com/questions/13386474/are-guava-11-0-2-jar-conflicting-with-com-google-common-1-0-0-0-0-6-jar) — Elye M., Nov 20 '12 at 14:10

score 11 · Answer 1 · answered Nov 13 '12 at 16:20

11

It looks like you're running against a different version of Guava than you compiled against. Possibly you are running against multiple versions of Guava, and you are randomly getting the wrong one. This may be happening if one of your other dependencies has wrongly bundled Guava.

To figure out where this copy of MoreExecutors is coming from, I've heard that you can find it reflectively by using this snippet in UserServer:

MoreExecutors.class.getProtectionDomain().getCodeSource().getLocation()

answered Nov 13 '12 at 16:20

Chris Povirk

3,738
3
29
47

No idea what i should do, can you give me more details ? tnx a mill! – Elye M. Nov 13 '12 at 21:07
2

@ElyeM. Add something like `System.out.println(MoreExecutors.class.getProtectionDomain().getCodeSource().getLocation())` (or using your logging system of choice) either in a static initialization block in `com.my.app.servers.UserServer` or more probably in `com.my.app.ActionServlet.init()` before line 167, so it executes before the exception is thrown. That will log the "path" of the jar which contains the loaded `MoreExecutors` class and help you get rid of the jar conflict. – Frank Pavageau Nov 14 '12 at 15:50
Okay first thanks! I did it and its coming from com.google.common_1.0.0.0_0-6.jar and it has to come from Guava-11.0.2.jar , what do you think I should do? I think I can’t just delete the com.google.common_1.0.0.0_0-6.jar file cuz its needed for the server, do you have any suggestions ? – Elye M. Nov 14 '12 at 17:43
You could try the weblogic-application.xml suggestion under "Clazzloading or Oracle and RedHat vs. Google" at http://blog.eisele.net/2011/12/running-richfaces-410final-on-weblogic.html – Chris Povirk Nov 14 '12 at 18:15
1

@ElyeM. the solution linked by Chris should solve your issue, as it's a classloading problem: WLS packages what looks like an old & repackaged version of google-collections, which has been superseded by Guava; By default, your application will "see" the classes loaded by WLS before the ones it packages, which is why you end up using the wrong `MoreExecutors` version. By filtering the packages exported by Guava from the application classloader, you'll be sure to use all the Guava classes coming from the jar packaged in your app, not the one in WLS itself. – Frank Pavageau Nov 15 '12 at 09:25
try my answer at this [thread](http://stackoverflow.com/a/17976553/2098832) should work for you as well. It uses weblogic.xml and FilteringClassloaders from WebLogic instead of jar replacement... – Casey Jul 31 '13 at 17:10

score 2 · Answer 2 · edited May 23 '17 at 12:17

It seems this a recurring question ([1], [2], [3]). I, myself, have stumbled upon this same problem. Weblogic is loading first it's own version of the (outdated) guava lib confliting with your applcation's version.

The solution is to add the prefer-application-packages to your weblogic.xml or weblogic-application.xml:

<wls:container-descriptor>
    <wls:prefer-application-packages>
            <wls:package-name>com.google.common.*</wls:package-name>
    </wls:prefer-application-packages>
</wls:container-descriptor>

score 1 · Answer 3 · answered Nov 13 '12 at 14:55

Is it a WAR project? Or is it just a EJB jar?

If the latest one, you've got a few options:

wrap your jar file into a EAR and deliver Guava's jar in it
add Guava's jar to the library folder of your AS
merge your jar file with Guava's one. For example, you can use Maven Shade Plugin if you're a Maven guy

score 1 · Answer 4 · answered May 26 '16 at 18:15

I faced the similar issue. I could resolve this problem by adding a weblogic-application.xml with prefer-application-packages to my EAR.

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://xmlns.oracle.com/weblogic/weblogic-application"
                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"                            xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.0/weblogic-application.xsd">
    <prefer-application-packages>
        <package-name>com.google.common.*</package-name>
    </prefer-application-packages>
</weblogic-application>

score 0 · Answer 5 · edited May 23 '17 at 12:34

I ran across this issue as well, unfortunately altering the weblogic.xml didn't work for me. What did work, was dropping the guava-14.0.1.jar into $JAVA_HOME/jre/lib/endorsed (create this directory if it doesn't exist.)

One other word of caution: at first I tried using the more recent guava-18 - this caused a compatibility issue the other way (IllegalAccessError on MapMaker.makeComputingMap - more details here). Guava 14.0.1 seems to hit the sweet spot for me - the MapMaker class is old enough to satisfy WebLogic while the MoreExecutors class is new enough to make the Cassandra Java driver work (which is how I stumbled upon this issue.)

score 0 · Answer 6 · answered Jul 25 '17 at 13:24

I managed to solve this problem using both files: weblogic-application.xml in ear and weblogic.xml in war

This is weblogic-application.xml in ear -> src/main/application/META-INF/

<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-application
    xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-application"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/javaee_5.xsd http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.4/weblogic-application.xsd">
    <wls:prefer-application-packages>
        <wls:package-name>com.google.common.*</wls:package-name>
    </wls:prefer-application-packages>
</wls:weblogic-application>

This is weblogic.xml in war -> src/main/webapp/WEB-INF/

<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-application
    xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-application"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/javaee_5.xsd http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.4/weblogic-application.xsd">
    <wls:prefer-application-packages>
        <wls:package-name>com.google.common.*</wls:package-name>
    </wls:prefer-application-packages>
</wls:weblogic-application>

Weblogic Guava issue when deploying application

6 Answers6

Linked