Hi Thorsten, I am not able to see the ConvertUtilsBean in the commons-beanutils-1-0.jar that I am using. Has this class been added in later versions of Struts? Also, is ConvertUtilsBean a singleton class or can I have multiple instances of it? Or if not, can I register multiple converters for say BigDecimal based on locale?
Regards, Nitin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, February 01, 2007 2:25 PM To: Struts Users Mailing List Subject: RE: Issue with registering/lookup of converters in ConvertUtils Nitin, I just took another look into the beanutils classes: there are not only the static classes (e.g., ConvertUtils), but also corresponding non-static classes (e.g., ConvertUtilsBean). You could create a Hashmap with Locale as its key and the ConvertUtilsBean configured with the locale specific converters. If you try it out, please tell us if it works ;) Cheers, Thorsten Zitat von Nitin Paul Dsilva <[EMAIL PROTECTED]>: > We too tried with the registering/deregistering of locale specific > converters. Apart from the bad performance, this will also result in > interference if the time of lookup that one session performs happens just > after the registering of the other session's converters. > We are looking at the option of extending a few of the struts classes which > are used in this flow with our own implementations to solve this. > But I just wanted to know if later versions of struts are handling this issue > or not. I will check with the commons guys regarding this. > > Regards, > Nitin > > -----Original Message----- > From: Thorsten Schäfer [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 01, 2007 12:10 PM > To: 'Struts Users Mailing List' > Subject: RE: Issue with registering/lookup of converters in ConvertUtils > > We had the problem with the latest stable Struts release (I don't know > if S2 handles the issue). In our implementation, it was ok to stick to a > single converter - so we did not need a workaround. IMHO, the problem is > not Struts, but the static nature of beanutils. Maybe you can ask the > commons guys for a solution!? One possible workaround is to register > locale specific converters always before they are used - however, this > is quite ugly and should have a bad performance. Maybe you take a look > into the implementation and find another workaround. > > Cheers, > > Thorsten > > > -----Original Message----- > > From: Nitin Paul Dsilva [mailto:[EMAIL PROTECTED] > > Sent: Thursday, February 01, 2007 5:34 AM > > To: Struts Users Mailing List > > Subject: RE: Issue with registering/lookup of converters in > ConvertUtils > > > > > > Hi, > > Thanks for the reply Thorsten. But the problem here is that such an > > implementation is already being used. But now we need to support > multiple > > formats for different users who login to the system. Is there any > other > > workaround for it other than copying parts of the implementation? > > > > > > Will it help if we move onto a higher version of Struts? > > > > Regards, > > Nitin > > > > > > -----Original Message----- > > From: Thorsten Schäfer [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, January 31, 2007 10:00 PM > > To: 'Struts Users Mailing List' > > Subject: RE: Issue with registering/lookup of converters in > ConvertUtils > > > > Hi, > > > > > Is there a problem with the registering/lookup of multiple > converters > > in > > > ConvertUtils on a single server instance? > > I think this is not possible. The converters are stored in a static > > hashmap, so all classes sharing a single classloader have to use the > > same converters. I consider this a bad design decision, but I don't > > think that there's a workaround but "copying" parts of the > > implementation... > > > > Cheers, > > > > Thorsten > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > **************** CAUTION - Disclaimer ***************** > > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > > solely for the use of the addressee(s). If you are not the intended > > recipient, please notify the sender by e-mail and delete the original > > message. Further, you are not to copy, disclose, or distribute this > e-mail > > or its contents to any other person and any such actions are unlawful. > > This e-mail may contain viruses. Infosys has taken every reasonable > > precaution to minimize this risk, but is not liable for any damage you > may > > sustain as a result of any virus in this e-mail. You should carry out > your > > own virus checks before opening the e-mail or attachment. Infosys > reserves > > the right to monitor and review the content of all messages sent to or > > from this e-mail address. Messages sent to or from this e-mail address > may > > be stored on the Infosys e-mail system. > > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
