About guava cannot be deployed in a JEE7 Container

Guava15.0在glassfish3.1.2.2上部署失败的问题源于JavaEE7CDI默认开启。通过调整beans.xml配置,可在glassfish4.0和3.1.2.2上部署。Guava16.0将移除@Singleton和@Inject注解,以避免此问题。
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
<think>好的,我现在需要解决用户遇到的Java编译错误:“AntiLong cannot be resolved to a type”。用户之前提供的引用内容涉及类似的问题,比如类无法解析的错误,比如Scanner、IOException等。现在我要根据这些引用和一般Java开发经验来分析可能的原因和解决方案。 首先,用户提到的错误信息是“AntiLong cannot be resolved to a type”,这通常意味着编译器在编译时不到这个类的定义。根据引用[3]中的情况,项目可能配置了不匹配的JDK,或者构建路径有问题。所以首先应该检查项目的JDK版本和构建路径是否正确。 其次,可能的情况是类名拼写错误。例如,用户可能将类名错误地写成了“AntiLong”,而正确的类名可能不同。比如,Java标准库中有没有这个类?如果用户自定义了这个类,是否存在拼写错误或者包路径的问题? 另外,引用[1]和[2]中提到的问题都是因为缺少导入语句或者类路径配置错误。如果AntiLong是用户自己定义的类,那么需要确认该类是否在正确的包中,并且被正确导入到当前类中。或者,如果AntiLong属于某个外部库,那么需要检查该库是否已经添加到项目的构建路径中。 接下来,可能的解决方案包括: 1. 检查类名拼写是否正确,确保AntiLong的类名与实际定义一致,包括大小写。 2. 确认AntiLong类所在的包是否正确导入到了当前使用它的类中。例如,如果AntiLong在com.example包中,当前类需要使用import com.example.AntiLong;。 3. 如果AntiLong是用户自己编写的类,检查是否已经正确编译,生成的.class文件是否位于正确的输出目录中。 4. 检查项目的构建路径,确认没有缺失的依赖库或源代码目录。例如,在Eclipse中,右键项目 -> Build Path -> Configure Build Path,检查Libraries和Source选项卡下的设置是否正确。 5. 确保项目使用的JDK版本与编译环境兼容,有时候使用过高的JDK版本可能导致某些类无法识别,但这种情况较少见。 6. 如果使用IDE,尝试清理项目并重新构建,有时候缓存可能导致问题。例如,Eclipse中的Project -> Clean功能。 7. 如果AntiLong属于第三方库,比如Apache Commons或Google Guava等,需要确认相应的JAR文件是否已经添加到项目的类路径中。 还需要考虑用户的具体情况。用户是否在项目中创建了AntiLong这个类?或者是否应该引用某个存在的库中的类?例如,是否有可能是用户想使用某个特定的类,比如Long的反向转换工具类,但类名拼写错误? 例如,假设用户想使用java.lang.Long,但错误地写成了AntiLong,这时候需要更正类名。或者,用户可能自定义了一个名为AntiLong的类,但忘记将其放在正确的包中,或者没有正确导入。 此外,根据引用[3]中的解决方案,修改项目的JDK配置也是一个可能的解决步骤。有时候项目配置的JDK与实际安装的版本不一致,导致某些类无法被正确解析。比如,项目可能配置为使用JRE而不是JDK,或者使用了错误的Java版本。 另外,如果用户使用的是Maven或Gradle等构建工具,可能需要检查依赖项是否正确配置,特别是如果AntiLong属于某个依赖项的话。例如,pom.xml或build.gradle文件中是否声明了相应的依赖。 总结可能的解决步骤: 1. 检查AntiLong类名的拼写是否正确。 2. 确认AntiLong类是否存在于正确的包路径中,并且在使用它的类中有正确的导入语句。 3. 验证项目的构建路径是否包含AntiLong类所在的源代码目录或JAR文件。 4. 检查项目的JDK配置是否正确,确保没有版本不匹配的问题。 5. 清理并重新构建项目,以消除可能的编译缓存问题。 6. 如果AntiLong是第三方库的一部分,确保该库已正确添加到项目中。 此外,用户可能需要检查是否有多个同名的类导致冲突,或者是否有其他编译错误影响了当前类的解析。有时候,一个错误可能导致后续的类无法被正确识别。 比如,用户可能在代码中有其他语法错误,导致编译器在处理到AntiLong时无法继续解析,从而报错。因此,检查代码中的其他错误也是一个重要步骤。 最后,根据用户之前的引用内容,特别是引用[3]提到的修改构建路径的方法,建议用户检查项目的构建路径配置,并确保所有必要的库和源代码目录都包含在内。</think>解决"AntiLong cannot be resolved to a type"错误需要系统性排查,以下是逐步解决方案: 1. **类名校验** - 检查类名是否拼写错误,注意Java区分大小写 - 确认是否应为`Long`或其他标准类名,如`java.lang.Long`[^3] 2. **自定义类验证** ```java // 确认存在对应类定义 public class AntiLong { // 类实现 } ``` - 检查类文件是否与使用类在同一包 - 跨包使用需添加import语句:`import com.example.AntiLong;` 3. **构建路径配置** - Eclipse操作路径:`项目右键 > Build Path > Configure Build Path` - 检查Libraries标签下是否缺失JRE System Library - 确认Source标签包含所有源代码目录[^3] 4. **JDK版本检查** - 通过`java -version`验证环境变量配置 - 在IDE中检查项目属性>Java Compiler>使用相同版本(推荐JDK8/11) 5. **依赖管理** - Maven项目需在pom.xml添加依赖: ```xml <dependency> <groupId>org.example</groupId> <artifactId>anti-long</artifactId> <version>1.0.0</version> </dependency> ``` 6. **工程清理** - 执行`mvn clean install`或`gradle clean build` - IDE执行Project > Clean **典型错误场景示例**: ```java // 错误:未导入自定义类 public class Test { public static void main(String[] args) { AntiLong al = new AntiLong(); // 报错 } } // 正确解决方案:添加import语句 import com.utils.AntiLong; ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值