[
https://issues.apache.org/jira/browse/OFBIZ-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrian Crum updated OFBIZ-1485:
-------------------------------
Attachment: props_tng.patch
While I was working on adding the XML properties file capability to
UtilProperties, I noticed a few things about the UtilProperties class that
bothered me. After the initial XML properties support was committed (rev
599356) I went back to the UtilProperties class to work on those issues.
#1 The caching algorithm in getInternalRbmWrapper(...) (line 493) - could
potentially store multiple copies of the same ResourceBundle in the cache.
#2 The getProperties(String resource, Locale locale) method wasn't fully
implemented (see notes at line 546).
Issue #1 was easy to fix - I just used the ResourceBundle.getLocale() method to
do a second cache lookup, around line 506. If one was found, I cached the new
key with the existing bundle. Now multiple locales could share a single
ResourceBundle instance. There was still the potential to have multiple copies
of the same ResourceBundle though. I'll get back to that later.
The solution to issue #2 was obvious - UtilProperties needed a properties file
location resolver. I already had one working in the XmlResourceBundle inner
class, so I just moved that code from the inner class to the outer class. I did
the same for the XML properties file to Map conversion code.
At this point, everything was working well - but something else started to
bother me. Why does UtilProperties have three caches? They all contain
basically the same thing. Technically, UtilProperties only needs two - one for
non-locale-specific properties, and one for locale-specific properties. I
changed the code a bit so that the ResourceBundle cache wasn't needed - I wrote
a method that wraps a XmlResourceBundle (renamed to UtilResourceBundle)
instance around an existing cached properties object. Methods that need a
ResourceBundle call the wrapper method. That eliminated one cache. That also
solved the issue that bugged me about the multiple same ResourceBundle
instances in the cache.
Now that the code was reduced down to two caches of FlexibleProperties objects,
I started to look at the FlexibleProperties class to see if there was a way to
convert it to a Javalution FastMap. So I traced through the
UtilProperties-to-FlexibleProperties code. I determined that the
FlexibleProperties object contributes nothing to the UtilProperties class. I
converted all references to FlexibleProperties to plain Maps, and used the
Javalution FastMap for new instances.
The final step was to rewrite bits of code so that UtilProperties would pass
around Maps internally, and only use the Properties class when one is requested.
The attached patch is the result. I have used it for about a week - it seems to
work well. The performance gains, memory savings, etc will have to be
determined by real-world installations.
Comments are welcome.
> UtilProperties - The Next Generation
> ------------------------------------
>
> Key: OFBIZ-1485
> URL: https://issues.apache.org/jira/browse/OFBIZ-1485
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
> Reporter: Adrian Crum
> Priority: Minor
> Attachments: props_tng.patch
>
>
> Improve the UtilProperties class. Details in comments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
