BundleTemplateMessage breaks with non-String ResourceBundles ------------------------------------------------------------ Key: SEAMINTL-44 URL: https://issues.jboss.org/browse/SEAMINTL-44 Project: Seam International Issue Type: Bug Components: Messages Affects Versions: 3.0.0.Final Reporter: Nicklas Karlsson Assignee: Ken Finnigan BundleTemplateMessages has in build() {code} try { text = bundles.get(clientLocale, textKey.getBundle()).getString(textKey.getKey()); } catch (Exception e) { log.warn("Could not load bundle: " + textKey); text = textDefault; } {code} which will result in a ClassCastException if the resource is non-string (because ResourceBundle.getString implementation casts getObject to String) and is further translated to a "Could not load bundle" warning followed by the BundleKey being outputted. Since ResourceBundle.getString is final, there is no way of overloading this behaviour. Using toString on a non-null resource would give some flexibility to this, perhaps.

BundleTemplateMessage breaks with non-String ResourceBundles ------------------------------------------------------------ Key: SEAMINTL-44 URL: https://issues.jboss.org/browse/SEAMINTL-44 Project: Seam International Issue Type: Bug Components: Messages Affects Versions: 3.0.0.Final Reporter: Nicklas Karlsson Assignee: Ken Finnigan BundleTemplateMessages has in build() {code} try { text = bundles.get(clientLocale, textKey.getBundle()).getString(textKey.getKey()); } catch (Exception e) { log.warn("Could not load bundle: " + textKey); text = textDefault; } {code} which will result in a ClassCastException if the resource is non-string (because ResourceBundle.getString implementation casts getObject to String) and is further translated to a "Could not load bundle" warning followed by the BundleKey being outputted. Since ResourceBundle.getString is final, there is no way of overloading this behaviour. Using toString on a non-null resource would give some flexibility to this, perhaps.

BundleTemplateMessage breaks with non-String ResourceBundles ------------------------------------------------------------ Key: SEAMINTL-44 URL: https://issues.jboss.org/browse/SEAMINTL-44 Project: Seam International Issue Type: Bug Components: Messages Affects Versions: 3.0.0.Final Reporter: Nicklas Karlsson Assignee: Ken Finnigan Fix For: 3.1.0.Alpha1 Original Estimate: 6 hours Remaining Estimate: 6 hours BundleTemplateMessages has in build() {code} try { text = bundles.get(clientLocale, textKey.getBundle()).getString(textKey.getKey()); } catch (Exception e) { log.warn("Could not load bundle: " + textKey); text = textDefault; } {code} which will result in a ClassCastException if the resource is non-string (because ResourceBundle.getString implementation casts getObject to String) and is further translated to a "Could not load bundle" warning followed by the BundleKey being outputted. Since ResourceBundle.getString is final, there is no way of overloading this behaviour. Using toString on a non-null resource would give some flexibility to this, perhaps.

BundleTemplateMessage breaks with non-String ResourceBundles ------------------------------------------------------------ Key: SEAMINTL-44 URL: https://issues.jboss.org/browse/SEAMINTL-44 Project: Seam International Issue Type: Bug Components: Messages Affects Versions: 3.0.0.Final Reporter: Nicklas Karlsson Assignee: Ken Finnigan Fix For: 3.1.0.Beta1 Original Estimate: 6 hours Remaining Estimate: 6 hours BundleTemplateMessages has in build() {code} try { text = bundles.get(clientLocale, textKey.getBundle()).getString(textKey.getKey()); } catch (Exception e) { log.warn("Could not load bundle: " + textKey); text = textDefault; } {code} which will result in a ClassCastException if the resource is non-string (because ResourceBundle.getString implementation casts getObject to String) and is further translated to a "Could not load bundle" warning followed by the BundleKey being outputted. Since ResourceBundle.getString is final, there is no way of overloading this behaviour. Using toString on a non-null resource would give some flexibility to this, perhaps.