Spring配置文件中的多个messageSource
我们的 Web 应用程序使用 Spring 2.5。它由多个模块组成，每个模块都可以带来额外的 Spring 上下文文件，这些文件会自动加载（到一个应用程序上下文中）。我们希望让每个模块提供额外的资源包（用于 I18N 支持）。
Spring 通过在配置文件中注册名为 messageSource 的 bean 来支持国际化，但这假设我确切地知道包含翻译字符串的类或属性文件的完全限定名称。这是一个问题，因为其他模块可能将自己的属性文件放在不同的位置。因此，我正在寻找一种方法，让每个模块使用自己的资源包定义自己的 messageSource，但我不知道该怎么做。
有人知道这个问题的解决办法吗？
谢谢。
our web application uses Spring 2.5. It consists of several modules, each of which can bring additional Spring context files, which are loaded automatically (into one application context). We want to let each module provide additional resource bundles (for I18N support).
Spring supports internationalization by registering a bean with name messageSource in the configuration file, but this assumes I know exactly what is the fully qualified name of the class or properties file that contained the translates strings. This is a problem because other modules might have their own properties files put in a different location. So I'm looking for a way to let each module define its own messageSource with its own resource bundles and I don't know how to do it.
Does anybody know the solution to this problem?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我已经使用 Spring 中的消息源来获得一些 i18n 支持。就我而言，我只需要一个，因此可以轻松地将我需要的一个消息源注入到我正在创建的服务 bean 中。
我希望看到类似我稍后将在 Spring 源代码中提出的内容。但我没有看到任何可以聚合异构消息源的东西。如果它们全部都是资源包（如属性文件）的一部分，我确信您可以为 ResourceBundleMessageSource 编写一个包装器，该包装器可以在注册 bean 时动态更新。
但是，如果您想聚合异构 MessageSource，这就是我的建议。创建一个消息源聚合 bean，加载时会向 ApplicationContext 请求 MessageSource.class 类型的 bean。然后，这个聚合 bean 可以让每个源尝试解析密钥并格式化消息。根据您拥有的文件/消息源类的数量，您可能希望允许聚合实现优先考虑首先尝试使用的文件/消息源类。如果性能成为问题，您还可以缓存哪个源解析了哪些键，以便聚合器不必每次都猜测。
I have used the Message Sources in Spring for some i18n support. In my case I only needed one so it was easy to inject the one message source I needed into the service bean that I was creating.
I was hoping to see something like what I will propose later on in the Spring sources itself. But I don't see anything that will aggregate heterogeneous message sources. If all of them will be parts of a resource bundle like property files, I'm sure you could write a wrapper for ResourceBundleMessageSource that could be dynamically updated as beans were registered.
However, if you wanted to aggregate heterogeneous MessageSources, this is what I would suggest. Create an message source aggregating bean that upon loading asks the ApplicationContext for beans of type MessageSource.class. This aggregating bean can then let each source attempt to resolve the key and format the message. Depending on how many files/msg source classes you have you may want to allow the aggregating implementation to prioritize which ones it attempts to use first. If performance becomes a problem, you could also cache which source resolved which keys so that the aggregator doesn't have to guess each time.