Moving this to dev list...
Could we discuss the best approach to making this change then? I checked out Jacques' link, and there seems to be two methods to get properties files to "hot load." In addition, David has suggested rewriting UtilProperties to not use the Resource Bundle. So, I see three approaches available: 1. Copy the ResourceBundle source code to our own class and modify it so the cache can be cleared. 2. Develop our own properties file loader/cache class that allows cache clearing, or - as was suggested in the article Jacques provided - check the file system regularly for properties file changes and reload them automatically. 3. Rewrite the UtilProperties class to eliminate using ResourceBundle and provide a way to clear the properties file cache. Comments anyone? Scott Gray wrote: > All depends on whether it bothers someone enough to code the changes, I > suspect it would be quite some time before OFBiz is using code specific to > that version of java. > > Regards > Scott > > On 13/04/07, Adrian Crum <[hidden email]> wrote: > >> >> So, where does that leave us? Do we just wait for Java 6 or make the >> change >> David suggested? >> >> >> Jacques Le Roux wrote: >> >> > Interesting, thanks Scott ! >> > >> > Jacques >> > >> > De : "Scott Gray" <[hidden email]> >> > >> >>It looks like they've fixed it in Java 6, it appears to be a popular >> > >> > issue: >> > >> >>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4212439 >> >> >> >>On 12/04/07, Jacques Le Roux <[hidden email]> wrote: >> >> >> >>>My answer was from experience ;o) >> >>> >> >>>Is there a Jira issue for that, should we create one ? >> >>> >> >>>Jacques >> >>> >> >>> >> >>>>This would be true except that we use the ResourceBundle class of >> > >> > the >> > >> >>>>Java API, and that class keeps its own cache that prevents >> > >> > reloading. >> > >> >>>>So for now we are stuck with a restart to reload on properties >> > >> > files. >> > >> >>>>We've been talking about rewriting the UtilProperties stuff to not >> >>>>use ResourceBundle (there are various notes in the java file on >> > >> > it), >> > >> >>>>but that hasn't been done yet. >> >>>> >> >>>>-David >> >>>> >> >>>> >> >>>>On Apr 12, 2007, at 2:49 AM, Scott Gray wrote: >> >>>> >> >>>> >> >>>>>I was under the impression the properties are loaded and cached >> > >> > the >> > >> >>>>>first >> >>>>>time the file is used and can be cleared via webtools >> >>>>> >> >>>>>Scott >> >>>>> >> >>>>>On 12/04/07, Jacques Le Roux <[hidden email]> >> > >> > wrote: >> > >> >>>>>> >> >>>>>>Deploying a classpath resource is similar to deploying a >> > >> > compiled >> > >> >>>>>>Java >> >>>>>>class : you have to reload. >> >>>>>> >> >>>>>>This article may be of interest in this field : >> >>>>>>http://www.javaworld.com/javaworld/javatips/jw-javatip125.html >> >>>>>> >> >>>>>>Jacques >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>>>Hi, >> >>>>>>> >> >>>>>>> >> >>>>>>>When you are working with files that are not using entity >> > >> > tags >> > >> >>>>>>>("<entity-engine-xml>"), such as 'arithmetic.properties' is >> > >> > there >> > >> >>>a >> >>> >> >>>>>>method >> >>>>>> >> >>>>>>>to load the data, or is the file called each time it is used. >> > >> > (I >> > >> >>>>>>did >> >>>>>>clear >> >>>>>> >> >>>>>>>the cache). >> >>>>>>> >> >>>>>>>I would like to understand this better, any guidance would be >> >>>>>> >> >>>>>>appreciated. >> >>>>>> >> >>>>>>> >> >>>>>>>Thanks & Regards, >> >>>>>>> >> >>>>>>>Peter >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>> >> >>> >> > >> > >> > |
To make the discussion a bit more interesting there is one other alternative I was looking at early on because of various problems with the ResourceBundle. First some of the problems related to using the ResourceBundle stuff: 1. properties files cannot be UTF-8 encoded 2. if the system language is not English the locale defaulting back to english is broken (because we use english as the language for our properties files without a locale suffix 3. changed properties files cannot be reloaded on the fly Because of these things early on I considered writing our own localization tool, probably based on an XML file rather than a properties file for more flexibility. Some thoughts on that: 1. can't use nice tools like some of the properties file management things; though with the other files we would design them so it wouldn't be so necessary... 2. could structure XML file so that there is a single element for each message ID, and then a sub-element for each alternate locale for the actual messages 3. could configure globally which locale to default to, and could more intelligently default with multiple locales for defaulting, ie try Mexico Spanish then Spain Spanish then English (will usually want English as a last resort since that is the most complete set of labels in OFBiz) 4. these XML files would be UTF-8 encoded so no tool would be necessary to move to/from the limited encoding with \uXXXX things and such Anyway... these kinds of features would be nice for localization efforts... If someone is interested enough it would be great to get this developed, or at least start pooling funds for sponsoring development or something. -David On Apr 13, 2007, at 10:43 AM, Adrian Crum wrote: > Moving this to dev list... > > Could we discuss the best approach to making this change then? > > I checked out Jacques' link, and there seems to be two methods to > get properties files to "hot load." In addition, David has > suggested rewriting UtilProperties to not use the Resource Bundle. > So, I see three approaches available: > > 1. Copy the ResourceBundle source code to our own class and modify > it so the cache can be cleared. > > 2. Develop our own properties file loader/cache class that allows > cache clearing, or - as was suggested in the article Jacques > provided - check the file system regularly for properties file > changes and reload them automatically. > > 3. Rewrite the UtilProperties class to eliminate using > ResourceBundle and provide a way to clear the properties file cache. > > Comments anyone? > > > Scott Gray wrote: > >> All depends on whether it bothers someone enough to code the >> changes, I >> suspect it would be quite some time before OFBiz is using code >> specific to >> that version of java. >> Regards >> Scott >> On 13/04/07, Adrian Crum <[hidden email]> wrote: >>> >>> So, where does that leave us? Do we just wait for Java 6 or make the >>> change >>> David suggested? >>> >>> >>> Jacques Le Roux wrote: >>> >>> > Interesting, thanks Scott ! >>> > >>> > Jacques >>> > >>> > De : "Scott Gray" <[hidden email]> >>> > >>> >>It looks like they've fixed it in Java 6, it appears to be a >>> popular >>> > >>> > issue: >>> > >>> >>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4212439 >>> >> >>> >>On 12/04/07, Jacques Le Roux <[hidden email]> wrote: >>> >> >>> >>>My answer was from experience ;o) >>> >>> >>> >>>Is there a Jira issue for that, should we create one ? >>> >>> >>> >>>Jacques >>> >>> >>> >>> >>> >>>>This would be true except that we use the ResourceBundle >>> class of >>> > >>> > the >>> > >>> >>>>Java API, and that class keeps its own cache that prevents >>> > >>> > reloading. >>> > >>> >>>>So for now we are stuck with a restart to reload on properties >>> > >>> > files. >>> > >>> >>>>We've been talking about rewriting the UtilProperties stuff >>> to not >>> >>>>use ResourceBundle (there are various notes in the java file on >>> > >>> > it), >>> > >>> >>>>but that hasn't been done yet. >>> >>>> >>> >>>>-David >>> >>>> >>> >>>> >>> >>>>On Apr 12, 2007, at 2:49 AM, Scott Gray wrote: >>> >>>> >>> >>>> >>> >>>>>I was under the impression the properties are loaded and cached >>> > >>> > the >>> > >>> >>>>>first >>> >>>>>time the file is used and can be cleared via webtools >>> >>>>> >>> >>>>>Scott >>> >>>>> >>> >>>>>On 12/04/07, Jacques Le Roux <[hidden email]> >>> > >>> > wrote: >>> > >>> >>>>>> >>> >>>>>>Deploying a classpath resource is similar to deploying a >>> > >>> > compiled >>> > >>> >>>>>>Java >>> >>>>>>class : you have to reload. >>> >>>>>> >>> >>>>>>This article may be of interest in this field : >>> >>>>>>http://www.javaworld.com/javaworld/javatips/jw-javatip125.html >>> >>>>>> >>> >>>>>>Jacques >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>>>Hi, >>> >>>>>>> >>> >>>>>>> >>> >>>>>>>When you are working with files that are not using entity >>> > >>> > tags >>> > >>> >>>>>>>("<entity-engine-xml>"), such as 'arithmetic.properties' is >>> > >>> > there >>> > >>> >>>a >>> >>> >>> >>>>>>method >>> >>>>>> >>> >>>>>>>to load the data, or is the file called each time it is used. >>> > >>> > (I >>> > >>> >>>>>>did >>> >>>>>>clear >>> >>>>>> >>> >>>>>>>the cache). >>> >>>>>>> >>> >>>>>>>I would like to understand this better, any guidance would be >>> >>>>>> >>> >>>>>>appreciated. >>> >>>>>> >>> >>>>>>> >>> >>>>>>>Thanks & Regards, >>> >>>>>>> >>> >>>>>>>Peter >>> >>>>>>> >>> >>>>>> >>> >>>>>> >>> >>>> >>> >>> >>> > >>> > >>> smime.p7s (3K) Download Attachment |
David E. Jones wrote:
> 2. could structure XML file so that there is a single element for each > message ID, and then a sub-element for each alternate locale for the > actual messages So, there would be one large XML file with all languages in it? > 3. could configure globally which locale to default to, and could more > intelligently default with multiple locales for defaulting, ie try > Mexico Spanish then Spain Spanish then English (will usually want > English as a last resort since that is the most complete set of labels > in OFBiz) I'm not an expert on this, but isn't the internationalization already set up to default to the basic language if a locale-specific dialect isn't found? Is there any reason why we couldn't take an evolutionary approach? Say, develop our own class that loads the existing properties files, let it cook for a while, then modify it later to use XML files? |
On Apr 13, 2007, at 5:25 PM, Adrian Crum wrote: > David E. Jones wrote: >> 2. could structure XML file so that there is a single element for >> each message ID, and then a sub-element for each alternate locale >> for the actual messages > > So, there would be one large XML file with all languages in it? Large or small, yeah, all languages in one XML file (if we want to do it that way, of course). >> 3. could configure globally which locale to default to, and could >> more intelligently default with multiple locales for defaulting, >> ie try Mexico Spanish then Spain Spanish then English (will >> usually want English as a last resort since that is the most >> complete set of labels in OFBiz) > > I'm not an expert on this, but isn't the internationalization > already set up to default to the basic language if a locale- > specific dialect isn't found? Yes, but you can't configure which locale is the default, or a chain of defaults, except in a limited way through the naming of files. Makes it really difficult to change that order... ie you have to rename dozens of files... > Is there any reason why we couldn't take an evolutionary approach? > Say, develop our own class that loads the existing properties > files, let it cook for a while, then modify it later to use XML files? We certainly could, but I don't know if the earlier effort would really benefit the later effort much. -David smime.p7s (3K) Download Attachment |
David E. Jones wrote:
>> Is there any reason why we couldn't take an evolutionary approach? >> Say, develop our own class that loads the existing properties files, >> let it cook for a while, then modify it later to use XML files? > > > We certainly could, but I don't know if the earlier effort would really > benefit the later effort much. The basic logic for loading, clearing cache, etc can be developed and tested. We have the benefit of testing the basic logic and giving it some good use before introducing the new file format. *shrug* It seems like a less risky/drastic approach to me. |
On Apr 13, 2007, at 5:47 PM, Adrian Crum wrote: > David E. Jones wrote: >>> Is there any reason why we couldn't take an evolutionary >>> approach? Say, develop our own class that loads the existing >>> properties files, let it cook for a while, then modify it later >>> to use XML files? >> We certainly could, but I don't know if the earlier effort would >> really benefit the later effort much. > > The basic logic for loading, clearing cache, etc can be developed > and tested. We have the benefit of testing the basic logic and > giving it some good use before introducing the new file format. > > *shrug* It seems like a less risky/drastic approach to me. only solves one of many problems. What I'm saying is that it's really not a step towards the other and the majority of the code used for a properties would be thrown away with an XML approach that has significantly different structure and features and such. -David smime.p7s (3K) Download Attachment |
Dear David,
You may know Apache commons configuration already, but if not, take a look at it. It has auto-reloading of config files, and can work with both XML and properties files (and DBs) through the same API. It may even do UTF-8, though I'm not sure. For localized resource bundles you would need to develop something, but maybe that can go into Apache commons again? Kind regards, -- -- Marco Nijdam, [hidden email] -- West Consulting B.V., Delftechpark 5, 2628 XJ Delft, The Netherlands -- Tel: +3115 219 1600, Fax: +3115 214 7889 As quoted from "David E. Jones" <[hidden email]>: > > On Apr 13, 2007, at 5:47 PM, Adrian Crum wrote: > > >David E. Jones wrote: > >>>Is there any reason why we couldn't take an evolutionary > >>>approach? Say, develop our own class that loads the existing > >>>properties files, let it cook for a while, then modify it later > >>>to use XML files? > >>We certainly could, but I don't know if the earlier effort would > >>really benefit the later effort much. > > > >The basic logic for loading, clearing cache, etc can be developed > >and tested. We have the benefit of testing the basic logic and > >giving it some good use before introducing the new file format. > > > >*shrug* It seems like a less risky/drastic approach to me. > > Yeah, certainly less risky and drastic, and lots less work, but it > only solves one of many problems. > > What I'm saying is that it's really not a step towards the other and > the majority of the code used for a properties would be thrown away > with an XML approach that has significantly different structure and > features and such. > > -David > |
Free forum by Nabble | Edit this page |