Problem with Guava 14.0.1, Erray.2.4.0.Final and WildFly.8.Beta1

[hr.stoyanov]

Not sure where I should report this, but let's start with the Errai forum: The included guava-14.0.1.jar is messing up Weld in WildFly.8.Beta1. It is OK in JBoss 7.2. However, if you upgrade to  guava-15.0.jar, you will start getting the same issue even in JBoss 7.2.

=====================================================

01:44:11,277 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."s4g-web.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."s4g-web.war".WeldStartService: Failed to start service

  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]

  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]

  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]

  at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]

Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default

  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)

  at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0)

  at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:361)

  at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:282)

  at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:133)

  at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)

  at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:507)

  at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)

  at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)

  at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)

  at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)

  at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_40]

  ... 3 more

01:44:11,284 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "s4g-web.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"s4g-web.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"s4g-web.war\".WeldStartService: Failed to start service

    Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default

  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)

  at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0)

"}}

01:44:11,288 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "s4g-web.war" was rolled back with the following failure message:

{"JBAS014671: Failed services" => {"jboss.deployment.unit.\"s4g-web.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"s4g-web.war\".WeldStartService: Failed to start service

    Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default

  at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)

  at com.google.common.util.concurrent.ServiceManager.<init>(ServiceManager.java:0)

"}}

[jfuerth]

Thanks for letting us know about this. We're aware of some issues with deploying Errai apps to Wildfly 8, and fixing these issues is high on our priority list.

-Jonathan

[jfuerth]

I've tried deploying the errai-tutorial project to WildFly 8 Beta1, and it worked properly. There were some warnings from Weld that we'll need to look at and clean up, but no fatal errors. The app deployed and worked as expected.

As for the Guava 14.0.1 dependency, we'll look into it. If you can live with 13.0.1, stick with that now. Unfortunately there is a disagreement between the dependencyManagement sections in errai-parent and errai-version-master, so we currently have some demos that use Guava 13 and others that use Guava 14. Errai itself will function properly on Guava >= 13.

-Jonathan

[hr_stoyanov]

Thanks Jonathan,

We downgraded to JBoss 7 for now. I will retry WIldFly 8 Beta 1 later today. The problem with Google's GUAVA  14.0.1 is that it is mandated by Errai itself, we would love to use Guava 15 for our app otherwise. I know that the Guava developers did some services registration stuff in 14.x and later, which probably includes changes to the manifest files in the guava jar. Unfortunately Weld in WildFly is scanning all these jars, picks up this service registration and kills the deployment with the above exception. So, the issue might be in Weld and/or Guava, rather than Errai. Maybe we can forward this email trail to the WildFly developers for investigation? Weld is used in both WildFly/JBoss and GlassFish, so this might be a bigger issue...

[jfuerth]

It looks like the wider discussion is going on in two different bug trackers:

The Guava tracker: https://code.google.com/p/guava-libraries/issues/detail?id=1433

And the CDI spec tracker: [CDI-377] automatic JSR-330 annotation processing problematic - JBoss Issue Tracker

Unfortunately, it looks like it will not be possible for the Guava team to work around this themselves, although they did demonstrate the willingness to do so. And the CDI 1.1 spec can't work around it since it is now set in stone.

It appears that you can work around the issue in your own app by declaring a producer method for the unsatisfied type:

@Produces Set<Service> guavaCdiClashWorkaround() {
  return ImmutableSet.of();
}

let us know if this works for you, and maybe we can just include this producer method in ErraiCDI.

-Jonathan