RE: Default bundles with JDK6
Jeremy, Close...here is what I'm doing in order to support ResourceBundle.Control. 1. Configure the TextProvider in struts.xml (constant struts.xworkTextProvider) 2. Our TextProvider impl extends TextProviderSupport and overrides getTexts(String name) - we call ResourceBundle.getBundle with a RB.C object 3. Configure the list of default resource bundles (constant struts.custom.i18n.resources) 4. An s:text within an s:i18n works fine since s:i18n calls getTexts 5. An s:text outside an s:i18n or getText method invocation does not work - the Class-based TP from the Action goes through all its RBs and doesn't find them (and that calls our TP) - it then tries to use the RBs defined as the defaults - this does not call our TP We've applied patches for TextProviders not being singletons and a patch to I18N to call getTexts and a few other patches but this one looks like it is just a bad design (treating struts2 and xwork messages as part of the standard customization mechanism - they are bootstrap - not configuration). Does that help? I've logged the bug but can't go to 2.1 branch as it is beta and my company won't allow that. Brian -Original Message- From: Jeromy Evans [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2008 23:33 To: Struts Users Mailing List Subject: Re: Default bundles with JDK6 Repko, Brian wrote: There's been no reply to this - is there something more that I can give folks for help on this? Sounds like a bug. This section has always seemed messy to me. There's been several changes here in the 2.1 branch. I don't completely understand your approach, but presume you have a common base class for your actions that delegates to your TextProvider implementation instead of the default. If not, you should (replace/extend ActionSupport and delegate to your TextProvider mixin). As the action is (usually) at the top of the stack, the first TextProvider found will be your implementation of the various getText methods and you can do whatever you like before delegating to XWork. Or have I misunderstood the need? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail message is being sent solely for use by the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by phone or reply by e-mail, delete the original message and destroy all copies. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Default bundles with JDK6
There's been no reply to this - is there something more that I can give folks for help on this? -Original Message- From: Repko, Brian [mailto:[EMAIL PROTECTED] Sent: Sunday, August 24, 2008 11:41 To: Struts Users Mailing List Subject: Default bundles with JDK6 We have a custom TextProvider that implements getTexts by calling ResourceBundle.getBundle(...) with a ResourceBundle.Control object in order to load the data from a database. However if we try to configure our bundles in the list of defaults (struts2.custom.i18n.resources), then they never get read. Seems that the issue is LocalizedTextUtil.findDefaultText calls LocalizedTextUtil.findResourceBundle as opposed to the TextProvider interface. The default implementation of TextProvider (TextProviderSupport) then calls into LocalizedTextUtil.findResourceBundle. We could do something like that if we don't find the RB in our our list. Is this a bug? I think that part of the issue is that the Struts2 and xwork messages (the framework defaults) need to be read in your way but our defaults need to be read in another way. Defaults really isn't our defaults - its the frameworks. Ways around this seems to be: 1. name our bundles to match the candidate bundles that get looked up by Class-based TextProviders 2. always put an s:i18n tag around our s:text tags (always use ResourceBundle-based TextProviders) This is Struts 2.0.11.2 / Xwork 2.0.5 - we've already had to patch alot in order to get this to work with custom TextProviders. Bug? Other work-arounds to try? Brian This e-mail message is being sent solely for use by the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by phone or reply by e-mail, delete the original message and destroy all copies. Thank you. This e-mail message is being sent solely for use by the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by phone or reply by e-mail, delete the original message and destroy all copies. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default bundles with JDK6
Repko, Brian wrote: There's been no reply to this - is there something more that I can give folks for help on this? Sounds like a bug. This section has always seemed messy to me. There's been several changes here in the 2.1 branch. I don't completely understand your approach, but presume you have a common base class for your actions that delegates to your TextProvider implementation instead of the default. If not, you should (replace/extend ActionSupport and delegate to your TextProvider mixin). As the action is (usually) at the top of the stack, the first TextProvider found will be your implementation of the various getText methods and you can do whatever you like before delegating to XWork. Or have I misunderstood the need? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
