Re: Modification to speed up s:text from StrutsLocalizedTextProvider

2020-09-21 Thread Greg Huber
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 AbstractLocalizedT

Re: Modification to speed up s:text from StrutsLocalizedTextProvider

2020-09-21 Thread Yasser Zamani
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

Re: Modification to speed up s:text from StrutsLocalizedTextProvider

2020-09-20 Thread Greg Huber
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

Re: Modification to speed up s:text from StrutsLocalizedTextProvider

2020-09-19 Thread James Chaplin
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

Re: Modification to speed up s:text from StrutsLocalizedTextProvider

2020-09-15 Thread Lukasz Lenart
wt., 15 wrz 2020 o 08:41 Yasser Zamani 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 cac

Re: Modification to speed up s:text from StrutsLocalizedTextProvider

2020-09-14 Thread Yasser Zamani
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 va

Re: Modification to speed up s:text from StrutsLocalizedTextProvider

2020-09-14 Thread Lukasz Lenart
wt., 15 wrz 2020 o 07:49 Yasser Zamani napisał(a): > So generally I think we can have a Map as a cache, if not found in cache > then searching and if found after search, saving in cache. I've seen > this mechanism in Struts in other places as well. This is already done, results of the scan are al

Re: Modification to speed up s:text from StrutsLocalizedTextProvider

2020-09-14 Thread Yasser Zamani
Maybe this functionality was needed to allow user to override higher layers defined values (?) Or maybe another user for any reason claim that current behavior is wanted. So generally I think we can have a Map as a cache, if not found in cache then searching and if found after search, saving in ca

Re: Modification to speed up s:text from StrutsLocalizedTextProvider

2020-09-14 Thread Lukasz Lenart
pon., 14 wrz 2020 o 10:43 Greg Huber napisał(a): > > I have a local modification that I do to speed up my app on how I get > screen text ie via > com.opensymphony.xwork2.util.StrutsLocalizedTextProvider. > > By default StrutsLocalizedTextProvider will scan the class packages > first for the messa

Modification to speed up s:text from StrutsLocalizedTextProvider

2020-09-14 Thread Greg Huber
I have a local modification that I do to speed up my app on how I get screen text ie via com.opensymphony.xwork2.util.StrutsLocalizedTextProvider. By default StrutsLocalizedTextProvider will scan the class packages first for the message and then if it cannot find it try ApplicationResources.