为什么春天@Value与@Controller不兼容？ [英] Why is Spring @Value incompatible with @Controller?

问题描述

我在寻找一个更好的理解这个问题。一种解决方法是pretty简单，即移动配置数据到其他类不具有代理/咨询缠着，但我觉得这个理解会更好的帮助我避免今后其他相关问题，所以我想任何解释任何人都可以提供。

I'm looking for a better understanding of this problem. A workaround is pretty simple, namely move the configuration data to another class that does not have proxies/advice wrapped around it, but I think understanding this better will help me avoid other related problems in the future, so I'd like whatever explanation anyone can provide.

我使用Spring 3.1.0.RELEASE与Spring STS和TC的vFabric服务器。实现使用@Controller类基本没什么REST服务器。这是所有伟大的（实际上，这是），但@Controller也@Transactional，并且之间的加载时间编织和TC的vFabric服务器，它打破@Value。

I'm using Spring 3.1.0.RELEASE with Spring STS and the vFabric tc server. Implemented a basic little REST server using a @Controller class. That's all great (really, it is), but the @Controller is also @Transactional, and between that and the load time weaving and the vFabric tc server, it breaks @Value.

@Controller
@RequestMapping("/hello")
public class MyAPI {

    @Value("${my.property}")
    private String prop;
    ...

    @Transactional
    handleRequest(...) ...


}

和一个属性文件app.properties：

And a properties file app.properties:

my.property = SUCCESS

这JUnit的下正常工作，与测试越来越有支撑设置为成功一MyAPI对象。但是，当应用程序被加载到的vFabric，我猜它会加载时间编织和代理。无论发生什么，有创建了两个MyAPI实例，一个有道具==有成功和另一个（这是不幸的处理HTTP请求中的一个）道具==$ {} my.prop。

This works fine under JUnit, with the test getting a MyAPI object that has prop set to "SUCCESS". But when the app gets loaded into vFabric, I'm guessing it gets load time weaving and proxying. Whatever happens, there are two MyAPI instances created, one which has prop == "SUCCESS" and another (which is unfortunately the one that handles the http request) which has prop == "${my.prop}".

因此​​，所有功能于所有我称之为魔法失效，这是我使用的东西像AOP最大的担忧。即使STS我不知道如何追查是什么问题背后的原因或计算出，如果这是一个严重的错误。如果它是一个错误，我不知道它是否是在春天，AspectJ的，在加载时织，或一个的vFabric错误，所以我甚至不知道从哪里发送错误报告。

So all-in-all I call this a failure of magic, which is my biggest concern with using stuff like AOP. Even with STS I don't know how to track down what is the cause behind the problem or figure out if this is a serious bug. If it is a bug, I don't know whether it's a bug in Spring, AspectJ, the load-time weaver, or vFabric, so I don't even know where to file a bug report.

因此​​，在理解这个任何帮助将是AP preciated。谢谢你。

So any help in understanding this would be appreciated. Thanks.

推荐答案

我想通了。这，的确是太多了魔力。

I figured it out. It was, indeed, too much magic.

我用Spring Roo的STS中产生的基本应用程序框架，然后用STS因为我们不想坚持下来提取出来袋鼠。

I used Spring Roo in STS to generate the basic app framework, then factored out Roo using STS as we didn't want to stick with it.

一件事袋鼠做一个最佳实践是创建两个春天上下文，一个用于整个应用程序，并限制为调度的servlet。究竟为什么，我还没有得到，但我猜他们想保持在presentation层的东西，如控制器，从蔓延到了共享服务层。这是很好的通过axtavt 构建twice\">。这是所有从我通过STS隐藏的。

One thing Roo does as a "best practice" is create two Spring contexts, one for the whole app, and one limited to the dispatcher servlet. Exactly why, I still haven't gotten to, but I guess they want to keep the presentation layer stuff, such as the Controllers, from creeping into the service layer that is shared. This was nicely explained by axtavt here. This was all hidden from me by STS.

在与小豆STS，在WEB-INF源是不是我期望它，在/ src目录/主/资源（这是在META-INF目录），但在替代/ src目录/主/ web应用程序，这是不是Java源代码目录，从而显示完全分开，只是/目标目录上面，所以我误以为它的输出文件夹。

In STS with Roo, the WEB-INF source is not where I expected it, under /src/main/resources (which is where the META-INF directory is) but instead under /src/main/webapp, which is not a Java source directory and thus shown completely separately, just above the /target directory, so I mistook it for an output folder.

在applicationContext.xml中，袋鼠已经插入了过滤器，以prevent从构建控制器应用程序上下文，如axtavt的职位说明，但也存在另一种过滤器，以消除扫描小豆生成的类。我把两个过滤器出来的同时，并不真正了解他们在那里什么，但认为他们只是袋鼠剩菜。

In the applicationContext.xml, Roo had inserted the filter to prevent the application context from constructing Controllers, as explained in axtavt's post, but it also put in another filter to eliminate scanning Roo generated classes. I took both filters out at the same time, not really knowing what they were there for but thinking they were just Roo leftovers.

所以，正在创建，现在我已经得到了控制器的两倍如之前解释。和一个在应用程序上下文获取分配了属性，因为它是使用applicationContext.xml中并找到的属性文件。但是，为什么没有他们俩获得的属性设置？

So now I've got the problem of the Controllers being created twice as explained before. And the one in the application context gets the property assigned, because it is using the applicationContext.xml and finding the properties file. But why weren't they both getting the properties set?

这让我回模糊的webapps文件夹中。里面的WEB-INF文件夹小豆已经把在web.xml（自然），并含有webmvc-config.xml文件弹簧夹。这个配置文件被设置为扫描，创建和刚才设置的控制器。 web.xml文件设置Web应用程序使用的applicationContext.xml和DispatcherServlet的使用webmvc-config.xml文件，所以我应该离开在applicationContext.xml过滤器，以避免双重创建。

Which gets me back to the obscured webapps folder. Inside the WEB-INF folder Roo had placed the web.xml (naturally) and a spring folder containing a webmvc-config.xml file. This config file was set up to scan, create, and set up just the Controllers. The web.xml file sets up the web app to use the applicationContext.xml and the dispatcherServlet to use the webmvc-config.xml, so I should have left the filter in the applicationContext.xml to avoid the double creation.

拼图的最后一块是这样的webmvc-config.xml文件。因为这是在该控制器才能完成设置的背景下，是文件需要有在＆lt;背景：物业占位符/＆GT;构造以及使得它所能找到的属性文件。

The final piece of the puzzle was this webmvc-config.xml file. Since that is the context in which the Controllers get set up, that file needed to have the <context:property-placeholder/> configured as well so that it could find the properties file.

这篇关于为什么春天@Value与@Controller不兼容？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！