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]
