About guava cannot be deployed in a JEE7 Container

guava 15.0 版本无法部署在glassfish3.1.2.2上，经过查找原因是关于javaEE7 CDI模式开启造成的，在guava issues 1433找到线索。
地址：https://code.google.com/p/guava-libraries/issues/detail?id=1433
简介：
In JEE7 CDI (CDI 2.0) is enabled by default (without a beans.xml needing to be present), with no standardized way of disable it.

com.google.common.util.concurrent.ServiceManager is annotated with @Singleton and has a constructor...

  @Inject ServiceManager(Set<Service> services) {
    this((Iterable<Service>) services);
  }

So any war or ear that contains a guava 14.0.1 jar suffers from CDI seeing this and trying to create the bean but failing and thus failing the entire war from loading.

This error is from Glassfish 4.0

[2013-05-23T15:08:35.664-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1369346915664] [levelValue: 1000] [[
  Exception while loading the app : CDI deployment failure: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>)]
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>)]

The same WAR also fails to deploy on Firefly 8.0 with a similar error.

Can guava be modified to not use the @Singleton and @Inject annotations?
也就是说，guava14.0.1版本在部署在glassfish 4.0上时会出类似问题，然后根据回复发现，guava15.0单独为了解决这个问题被加入了一个beans.xml:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       bean-discovery-mode="none">
</beans>
这样，guava15.0便可以在glassfish4.0（支持javaEE7）上发布，但是仍不支持3.1.2.2（Oracle官方版本现在只有3.1.2.2），回复中有遇到相同问题的，最后将beans.xml换为一下，便可以支持两个版本了：
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:weld="http://jboss.org/schema/weld/beans"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd
                           http://jboss.org/schema/weld/beans http://jboss.org/schema/weld/beans_1_1.xsd">

    <weld:scan>
        <weld:exclude name="com.google.**"/>
    </weld:scan>
</beans>
glassfish4.0 是刚发布的版本，这是首个兼容 Java EE 7 企业级标准的应用服务器，下图是 Java EE 7 的 API 版本规范：


根据回复，guava在16版本会通过删掉inject来彻底解决这个问题，而CDI guys 却把这个当作good bug，可能短时间内不改，关注guava新版本，这样就不用手动改动jar包来解决问题了。另外，glassfish 3.1.2.2考虑升级到  GlassFish 4 Open Source Edition

So, both guava-14.0.1 and (strangely enough) guava-15.0-cdi1.0 *are* CDI agnostic. They only use JSR-330 annotations. To be clear: CDI itself is the problem here, because its specification prevents the use of libraries that annotate classes with certain JSR-330 annotations.

We're removing the annotations in Guava 16.0 because we feel that A) it seems unlikely that CDI will fix its spec anytime soon, and B) the problems this causes for users in CDI environments (where there apparently isn't any good workaround) probably outweighs the benefits of the annotations to users who are taking advantage of them in other environments (because at least with other JSR-330 frameworks like Guice and Dagger, binding the ServiceManager yourself isn't hard). It's not because we believe it's wrong for Guava to use the annotations; quite the opposite.
最终解决方案确定为删除guava 中的beans.xml，因为glassfish3.1.2.2是javaee6