Hi, In response to https://issues.apache.org/bugzilla/show_bug.cgi?id=46915, the Tomcat code was patched and 6.0.20 has now reverted back to the old behaviour of throwing an exception for every element in a resource bundle that can't be found.
Personally, I find this unfortunate. The "new" method of simply outputting the key name surrounded by ??? was much easier to develop with. It used to be that you could implement your page, and already put in the keys you needed, and still have it render (just with the ???foo?? strings). Then, when you were done with the layout/code, you could copy/paste all the ??? keys into the props file and fill them out. Now, even the slightest typo will result in an exception, which means that you either have to take out the key temporarily, or fix the props file immediately and, here's the kicker, restart your webapp. The old "new" way (just surround the keys with ???) was a lot better for development. Also, should any errors sneak their way into your production app, I think it's better to render a page that might have some "???" somewhere (if the text is even visible) rather than knocking the user over the head with a stacktrace/error page. I realize that you should check your apps for errors, that this scenario should never take place, etc. etc., but the fact is that it does happen, and throwing an exception for a missing resource bundle key seems a little draconic. So, my question is, why was the behaviour of ResourceBundleELResolver rolled back to what it was in the 5.5 branch? What's so terrible about the "???" method that it warrants the hit that developer productivity takes when you start throwing exceptions instead? Regards, Maarten -- View this message in context: http://www.nabble.com/Why-was-the-behaviour-of-ResourceBundleELResolver-tp24499717p24499717.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
