The overriding would be the main issue, but only if you override the properties.
It is 2000+ on each page render, list with 10 entries. Think caches the
bundle/locations, not what class/bundle, so it calls findResourceBundle(..)
with the key.
If you put a trace on your own
AbstractLocalizedTextProvider.findResourceBundle(..), and see what it does.
if (missingBundles.contains(key)) {
System.out.println("Miss : " + key);
return null;
}
My structure:
my.app.backoffice.struts2.list
my.app.backoffice.struts2.base
MyList extends MyListBase >> MyListBase extends BaseAction >> BaseAction
extends ActionSupport
If I had bundles they would really only be in .display or .base not in these
keys:
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
For me, checking the ApplicationResources.properties first brings back Struts1
response (for those who can can remember that far back!)
On 21/09/2020 16:56, Yasser Zamani wrote:
I think we have to search hierarchy all provided we want to support
overridden text (even if you define some convention about location).
So the only solution I can imagine is caching if applicable. Do you get
2075 on each page render or just first? Lukasz said we have caching and
you wouldn't get on each render.
Regards.
On 9/20/2020 12:52 PM, Greg Huber wrote:
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
---------------------------------------------------------------------
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
