如何在不重新启动服务器的情况下动态更新 JSF2.0 (Primefaces) 工具提示
我需要动态更新 JSF2.0 (Primefaces) 工具提示,而无需重新启动服务器。
这意味着需要找到一种方法,可以在不需要重新启动服务器的情况下更改正在运行的应用程序的工具提示(来自属性文件的 atm)。
我们正在运行 websphere 并部署一个非爆炸式 EAR(可能会说服部署爆炸式战争)
请提供任何想法或提示。感谢您
I need to update the JSF2.0 (Primefaces) tooltips dynamically without server restart.
Meaning need to find a way where tooltips (atm from properties file) of the a running application can be changed without requiring a server restart.
We are running websphere and deploying a non exploded EAR (can probably convince to deploy exploded war)
Any Ideas or tips please. Thanks you
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
p:toolTip
组件的value
属性必须是 EL 表达式或文字文本。通常,人们会在工具提示的 EL 表达式中引用使用f:loadBundle
标记的var
属性声明的资源包。使用
basename
属性声明的底层资源包可以由属性文件本身支持(在这种情况下,您需要将属性文件放置在类路径上的适当目录中),或者就此而言,它可以是一个自定义的 ResourceBundle 实现,可以从属性文件(位于容器外部)、数据库或任何与此相关的存储中读取。因此,您可以将现有的 EL 表达式从定义为: 的现有表达式更改为:
更
简单地说,您将需要推出自己的 ResourceBundle 类来支持各种语言环境。无需说明,但您需要覆盖
ResourceBundle.getObject(java.lang.String)
方法,因为它由ResourceBundleELResolver
评估 EL 时的实现引用 ResourceBundles 的表达式。此外,您需要确保 ResourceBundle 的
ResourceBundle.getObject(java.lang.String)
实现始终重新获取并返回与所提供的键对应的值。如果无法确保这一点,则意味着资源包获取的初始值可能会在后续调用中返回,尤其是在缓存初始值的情况下。即使您部署了分解的 WAR 文件(您可以在其中修改属性文件内容而无需重新部署应用程序),您也可能会遇到此行为,这就是为什么使用不缓存值的自定义 ResourceBundle 实现非常重要。The
value
attribute of thep:toolTip
component must be an EL expression or a literal text. Usually, one would reference a resource bundle declared using thevar
attribute of thef:loadBundle
tag, in the EL expression for the tooltip.The underlying resource bundle declared using the
basename
attribute could be backed by a property file itself (in which case you need to place the property file in the appropriate directory on the classpath), or for that matter it could be a custom ResourceBundle implementation that could read from a properties file (located outside the container), or a database or any store for that matter.You could therefore change your existing EL expression from the existing one defined as:
to
In simpler words, you will need to roll your own ResourceBundle class(es) to support the various locales. Needless to state, but you will need to override the
ResourceBundle.getObject(java.lang.String)
method, as it is invoked by theResourceBundleELResolver
implementation when evaluating the EL expressions referencing ResourceBundles.Additionally, you will need to ensure that the
ResourceBundle.getObject(java.lang.String)
implementation of your ResourceBundle will always re-fetch and return the value corresponding to the provided key. Failure to ensure this would mean that the initial value fetched by the resource bundle may be returned on subsequent invocations, especially if you are caching the initial value. You are likely to encounter this behavior even if you deploy an exploded WAR file where you can modify the property file contents without a redeployment of the application, and that is why it is important to use a custom ResourceBundle implementation that does not cache values.