Han,

Thanks for your cue.

After more than three hours research and test, I haven't resolve the problem yet. If 
my understand is right, what you 
suggested is to have the following code frame in the JSP page:

<fmt:bundle basename="org.apache.taglibs.standard.examples.i18n.Resources">   <---- I 
had this line at the very 
begining of the page
 <fmt:message>
  greetingMorning
 </fmt:message>
</fmt:bundle>   <----- at the bottom of the page

The problem doesn't go away with this change. 

In regarding of the number of resource files, the memory usage is around 70 m after 
the server is up if three files are 
there; compare to 20m if only two files. About 450 items are in each file.

I believe we had discussed the selection of two resource implementation before. The 
reason I don't use the  
ListResourceBundle is that a Java code change is needed, if messages are added (in the 
presentation lay).

It will be greatly appreciated if you can elaborate the usage of two tags: setBundle 
and bundle to resolve the problem.

Thanks,

Vernon  


7/29/2002 6:30:44 PM, Jan Luehe <[EMAIL PROTECTED]> wrote:

>Vernon,
>
>you should be able to avoid unnecessary loading of resource bundles by
>using the <fmt:setBundle> and <fmt:bundle> tags.
>
>If you use <fmt:setBundle> at the beginning of your page, it will
>establish a localization context and store the appropriate resource
>bundle in it. Any subsequent <fmt:message> actions will leverage this
>resource bundle, instead of loading their own.
>
>Alternatively, you may encapsulate your <fmt:message> actions in a
><fmt:bundle>, in which case the <fmt:message> actions will use the
>resource bundle of the localization context established by the
>enclosing <fmt:bundle> action.
>
>Unless I'm mistaken, this should result in loading a *single* resource
>bundle from the 3 resource bundles ("default", "en", and "zh") you
>configured with your application.
>
>Also, have you thought of providing your resource bundles as instances
>of java.util.ListResourceBundle as opposed to property files? I've
>attached org.apache.taglibs.standard.examples.i18n.Resources_de, which
>is used by standard-examples.war. Every call to
>ResourceBundle.getBundle() requesting this resource bundle will still
>create a new instance of this class, but this should be cheaper than
>parsing a properties file. Also note that the resource map
>("contents") is declared as a class variable, so the runtime won't
>create a copy of it for every instance generated.
>
>
>Jan
>
>
>
>> Vernon Wu wrote:
>> > 
>> > Peter,
>> > 
>> > Thanks for your suggestion.
>> > 
>> > Can you clarify the statement: "the data in the resource files are static"?
>> > 
>> > In regarding of the five options you mentioned:
>> > >1. use the cache tag, which uses fmt tag
>> > >2. write a custom tag which caches it as someone else mentioned
>> > 
>> > The caching mechanism only works when at least portion of data has be 
>retrieved early.
>> > In my case, only a small among data, if there is any, has be retrieved 
>before the page from the resource file. So these
>> > two approaches might not solve the problem
>> >
>> 
>> hmm, if I am reading you correctly, from request to request, the cached
>> data from the resouce files may be limited. Caching wouldn't really
>> help, unless it doesn't expire any loaded data. If that is the case, you
>> might be better off loading all the stuff statically when tomcat starts
>> up and register file events on the resouce files to get dynamic updates.
>> 
>> > >3. write a custom tag that extends the fmt tag
>> > 
>> > What is the goal of this extension? Is it to refine the fmt tag implemention 
>so that it will not eat up the much memory? Or
>> > to have the caching mechanism on?
>> 
>> You have several different ways of doing this right.  If the default
>> properties/resourcebundle class is too slow, you could write a custom
>> bean that takes advantage of nbio to improve the performance. 
>> 
>> > 
>> > >4. patch fmt tag to cache it and submit the patch to shawn
>> > 
>> > I would like to do that once I am free from current project.
>> > 
>> > >5. you can write a custom extension to the resource bundle that does the
>> > >caching. that will allow you to use fmt tag as is and have your resource
>> > >extension do the caching
>> > 
>> > For a set of large size resource files, this approache also comsumes a lot 
>of memory and it will hold the memory during
>> > the life time of the application.
>> > 
>> > Please point out if I am in any above statements.
>> > 
>> > BTW, the reason of more than 200 items in the resource files is man sets of 
>check boxes and pull down lists in the
>> > page. Is any way I can cut short the items in resource file?
>> 
>> Another option is you can break your resource files into smaller chunks
>> based on most-to-least used. The nvpair used 80% of the time can be
>> cached and loaded at startup. you could then write a custom tag that
>> first looks at the cache before getting it from the appropriate resource
>> file.
>> 
>> I hope that helps.
>> 
>> peter
>> 
>> --
>> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>> 
>
>package org.apache.taglibs.standard.examples.i18n;
>
>import java.util.*;
>
>public class Resources_de extends ListResourceBundle {
>    private static Object[][] contents;
>
>    static {
>       contents = new Object[][] {
>           { "greetingMorning", "Guten Morgen!" },
>           { "greetingEvening", "Guten Abend!" },
>           { "serverInfo", "Name/Version des Servlet Containers: {0}, "
>                           + "Java Version: {1}" },
>           { "currentTime", "Heutiges Datum und Uhrzeit: {0}" },
>           { "com.acme.labels.cancel", "Abbrechen" },
>           { "java.lang.ArithmeticException", "/ durch 0" }
>       };
>    }
>
>    public Object[][] getContents() {
>       return contents;
>    }
>}
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to