James,
After a rethink I came to the same conclusion, the most efficient way is
to check ApplicationResources.properties first, but as Lukasz points out
the properties cannot be override higher up in the class hierarchy.
Which I guess would be an issue for some. One resolution would be use an
alternative default location, ie in a package.properties in
main/resources/myorg/. Same basic location as
ApplicationResources.properties, but there are now two places needing
maintenance, and could get messy requiring too much testing.
I will have a look at the text-provider example, but
StrutsLocalizedTextProvider does not look too bad, it is
AbstractLocalizedTextProvider.findMessage(..) which seems expensive, as
it does recursive call in every which way possible.
One of my screens does 2075 calls to
AbstractLocalizedTextProvider.findResourceBundle(..), with some of the
(needless?) checks for each s:text used:
Miss : 1519736165com.opensymphony.xwork2.ActionSupport_en_GB
Miss : 1519736165com.opensymphony.xwork2.Action_en_GB
Miss : 1519736165com.opensymphony.xwork2.Validateable_en_GB
Miss : 1519736165com.opensymphony.xwork2.interceptor.ValidationAware_en_GB
Miss : 1519736165com.opensymphony.xwork2.TextProvider_en_GB
Miss : 1519736165com.opensymphony.xwork2.LocaleProvider_en_GB
Miss : 1519736165java.io.Serializable_en_GB
Miss : 1519736165java.lang.Object_en_GB
Miss : 1519736165com.opensymphony.xwork2.package_en_GB
Miss : 1519736165com.opensymphony.package_en_GB
Miss : 1519736165com.package_en_GB
eg limiting these to a hierarchy of
myorg.myapp.whatever.struts2.myAction would help, but messy.
Cheers Greg
On 19/09/2020 17:11, James Chaplin wrote:
Hello Everyone (and Greg, Lukasz and Yasser more specifically).
There are probably differing opinions on what constitutes "best practice"
for properties/resource bundles and Struts 2, but as long as the set-up you use for your
application functions effectively for you, it is probably OK. I find having a single set
of global properties convenient and easy to read, but it might not be as flexible as
having multiple/hierarchical property files.
Greg's proposal to change the order of lookup (scan the global
ApplicationResources.properties first) is interesting, but might have some
unintended impacts to applications whose behaviour depends on the current
lookup order. If there is a way to introduce the idea without impacting
preexisting applications, that would be ideal.
I wonder if providing an opt-in (either by configuration flag or
specifying the provider/factory) LocalizedTextProvider variant, with a lookup
order change similar to what Greg proposed, might be a reasonable compromise ?
Since the current default LocalizedTextProvider does its look-ups "bottom-up", the
new variant (or existing one with behaviour modified via configuration flag) could do its look-ups
"top-down" (starting at the global ApplicationResources.properties and then proceeding in
an opposite order to the current default). Essentially, it would be more efficient for
single-property-file applications, as in Greg's scenario (vs. the existing one which is more
efficient for class/hierarchy text).
Since developers can implement their own LocalizedTextProvider instances
(the Struts Examples https://github.com/apache/struts-examples/ text-provider
example provides a starting point), the Struts 2 Core should probably only need
to cover the most common usage patterns. There is already a
GlobalLocalizedTextProvider implemented, but it only looks at the global
application bundle (so its JavaDoc comments are misleading).
What do you folks think ?
Regards,
James.
On 2020/09/15 08:16:53, Lukasz Lenart <lukaszlen...@apache.org> wrote:
wt., 15 wrz 2020 o 08:41 Yasser Zamani <yasserzam...@apache.org> napisał(a):
Hi Lukasz :)
Excuse me... do you remember the place where caching occurs please? I
found some references of StrutsLocalizedTextProvider.getText and
followed up their parents. Also saw TextProviderSupport.java. I couldn't
find any cache for founded text :( Maybe because it's dependent to
current valueStack and cannot be cached (?)
This is combination of bundlesMap and missingBundles, also please be
aware that ResourceBundle.getBundle() does caching as well
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
