如何在不重新启动服务器的情况下动态更新 JSF2.0 (Primefaces) 工具提示

发布于 2024-11-19 14:12:47 字数 196 浏览 2 评论 0原文

我需要动态更新 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

情话墙 2024-11-26 14:12:47

p:toolTip 组件的 value 属性必须是 EL 表达式或文字文本。通常,人们会在工具提示的 EL 表达式中引用使用 f:loadBundle 标记的 var 属性声明的资源包。

使用 basename 属性声明的底层资源包可以由属性文件本身支持(在这种情况下,您需要将属性文件放置在类路径上的适当目录中),或者就此而言,它可以是一个自定义的 ResourceBundle 实现,可以从属性文件(位于容器外部)、数据库或任何与此相关的存储中读取。

因此,您可以将现有的 EL 表达式从定义为: 的现有表达式更改为:

<f:loadBundle var="msg" basename="propfile_location" />

<f:loadBundle var="msg" basename="fully qualified class name of the ResourceBundle class" />

简单地说,您将需要推出自己的 ResourceBundle 类来支持各种语言环境。无需说明,但您需要覆盖 ResourceBundle.getObject(java.lang.String) 方法,因为它由 ResourceBundleELResolver 评估 EL 时的实现引用 ResourceBundles 的表达式。

此外,您需要确保 ResourceBundle 的 ResourceBundle.getObject(java.lang.String) 实现始终重新获取并返回与所提供的键对应的值。如果无法确保这一点,则意味着资源包获取的初始值可能会在后续调用中返回,尤其是在缓存初始值的情况下。即使您部署了分解的 WAR 文件(您可以在其中修改属性文件内容而无需重新部署应用程序),您也可能会遇到此行为,这就是为什么使用不缓存值的自定义 ResourceBundle 实现非常重要。

The value attribute of the p:toolTip component must be an EL expression or a literal text. Usually, one would reference a resource bundle declared using the var attribute of the f: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:

<f:loadBundle var="msg" basename="propfile_location" />

to

<f:loadBundle var="msg" basename="fully qualified class name of the ResourceBundle class" />

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 the ResourceBundleELResolver 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文