我们有一个Spring 3.1 MVC应用程序打包为WAR,部署在GlassFish 3应用程序服务器上。该应用程序曾经是基于XML的Spring 2,在迁移到Spring 3之后,我们慢慢地将它重构为基于注释的IoC配置。
该应用程序的核心部分之一是自定义bean工厂,它为远程EJB执行普通的JNDI查找。但是,查找的参数存储在外部属性文件中,该文件可以在运行时更改 - 因此需要自定义工厂。我们还没有找到一种方法来配置工厂通过注释生成的bean,因此配置仍然是XML格式:
<bean id="exampleEjb" factory-method="lookup"
class="com.example.EjbServiceLocator" lazy-init="false" scope="session">
<constructor-arg value="example.ejb.connstr" /> <!-- remote hosts: x.y.z.1:3701,x.y.z.2:3701 - cluster here! -->
<constructor-arg value="example.ejb.name" /> <!-- JNDI name: ejb/example/remoteService -->
<constructor-arg value="com.example.service.RemoteInterface" /> <!-- this is interface exposed by remote bean -->
<constructor-arg ref="configReader" /> <!-- custom bean monitoring configuration changes -->
</bean>
在这里使用工厂意味着容器看到的bean类是com.example.EjbServiceLocator
而不是com.example.service.RemoteInterface
。按类型自动装配变得混乱,@Autowire
注释与@Qualifier
提供的bean名称的预期类型不匹配。所以我们必须使用@Resource(name="exampleEjb")
。
嗯,它有效。有一个“但是”。每次(重新)部署应用程序时,应用程序服务器都会扫描存档并尝试自行管理@Resource
注释。它失败了,在日志中留下了丑陋的 SEVERE 消息,导致我们的支持部门心率加快。
我在这里可以做什么:
@Resource
注释更改为Java EE容器无法识别的内容?答案 0 :(得分:1)
对于第1点:
您可以尝试将metadata-complete="true"
属性添加到web.xml文件中的webapp
元素,这样可以防止容器扫描和解析@Resource
注释。
对于第2点,第3点:
实现Spring Factory Bean可能是更好的选择,这样您就可以使用getObjectType()
api指定预期的确切类型。