https://issues.apache.org/bugzilla/show_bug.cgi?id=49426
--- Comment #5 from Marc Guillemot <mguille...@yahoo.fr> 2010-06-15 03:11:56 EDT --- (In reply to comment #4) > (In reply to comment #3) > > OK, you're right. What about holding the ResourceBundle in a ThreadLocal? > > Given all the issues we have seen with memory leaks and ThreadLocals I'd > rather not. > > Some additional thoughts: > - we could just pass the Locale around with the writer this would be the only solution when ThreadLocal is not wanted. I didn't want to choose this way as it means more changes but I can do it. Rather than passing writer and Locale (or ResourceBundle) everywhere along the way, I could imagine having a wrapper for both. > - I wonder how hard it would be to extend StringManager (efficiently - which > may be the slightly tricky bit) to support multiple Locales this wouldn't solve previous point: you have to be able to access the Locale each time you need to get a String. Additionally StringManager is quite useless. StringManager's cache doesn't make sense as java.util.ResourceBundle has already one. This means that the only value of StringManager is the facility method getString(final String key, final Object... args). > - in determining which Locale to use we need to call request.getLocales() and > check each in turn until we find a suitable match. this is correct. I didn't do it to keep the patch smaller in a first time but I can adapt patch (including unit test) for that now if you want. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
