Re: Validation in Nightly Build 20021105
Robert, Robert Leland wrote: Ok, it looks like it isn't the same bug, though the error is occuring in the iterator of the FastHashMap. I remember being hit by this a couple of weeks ago, while looking at a different problem. I don't think its the same problem I believe you said it was also happening in the Struts example/struts-validator program. Indeed. Except it failed for both the locale settings we tried, but we're not sure why. Be sure to mention the application server you're using. It was tomcat 4.0.4 in both cases. I'll add it to the bug report I'm about to write. I'll raise it on the commons-validator, as it appears to be the ValidatorResources object thats at fault here. I haven't had to worry about the locale being different being a Yank, but would like to be able to test this. How can I set the locale in my browser ? Is it the same as setting the language in the Mozilla preferences ? For Mozilla, yes. Edit - Preferences - Navigator - Languages. Hit Add, then select a language. Then move the new entry up above the en-us setting. For IE, it takes the setting from the whole machine. ControlPanel - Regional settings - somewhere. On changing, the value gets reflected in the session-scope attribute org.apache.struts.action.LOCALE, to be either en_US or en_GB (When debugging, we tend to include an extra JSP into the output, that renders all the application, session request-scope attributes, plus a button to display them in a pop-up. Very useful...) Cheers, Mike -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: Validation in Nightly Build 20021105
Mike Wilcox wrote: It was tomcat 4.0.4 in both cases. I'll add it to the bug report I'm about to write. I'll raise it on the commons-validator, as it appears to be the ValidatorResources object thats at fault here. There is already a bug reported, still state NEW, #14398 that covers this issue. I applied the patch in that bug to the 1.0 source, and rebuilt commons-validator.jar. Hey presto, all works fine. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14398 Next time, I'll remember to look in the buglist as well as the mailing list :) Thanks for the help, Mike -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: Validation in Nightly Build 20021105
Mike Wilcox wrote: I'll raise it on the commons-validator, as it appears to be the ValidatorResources object thats at fault here. Too quick on the send button there. The bug was actually #14384 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14384 Mike -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Validation in Nightly Build 20021105
Hi, We recently upgraded from Struts 1.1b1 to the nightly build from 20021105. After a couple of days, we realised that validation wasn't working because of a format change to setting the properties in struts-config.xml for the filenames. Once we fixed this, validation *sometimes* didn't work. The symptom is that in the output, where the html:javascript tag is placed (with only a formName attribute), we now render a whole bunch of Javascript - the static validation functions only, without the dynamic part, or any start or end tags to hide it. Now, Browser A (Mozilla 1.1, linux) works on server X, Browser B (IE6 on winXP) fails. However, Browser A fails on server Y, yet Browser B works. Checking the doStartTag() code showed me that these symptoms occur when the formName definition can't be found in the config data, utilising some locale info. Our logs show that the definition was found at startup, and this definition used to work in the older version of struts. Seeing a recent problem with a french locale, we checked. Browser A is using the en_US locale, while Browser B uses en_GB. We then swapped the locales used by the browsers, and the failure swaps round too. On checking, server X is in locale en_US while server Y is in locale en_GB. So... the browser/server combination worked when locales matched, and failed otherwise. We only have a single formset in the validation.xml, unqualified by country or language. However, if we do try to specify country or language, we get a NullPointerException in the commons-validator. 2002-11-13 17:22:24,104 [ main] ERROR he.struts.validator.ValidatorPlugIn - java.lang.NullPointerException at org.apache.commons.validator.ValidatorResources.processForms(ValidatorResources.java:355) at org.apache.commons.validator.ValidatorResources.process(ValidatorResources.java:319) at org.apache.struts.validator.ValidatorPlugIn.initResources(ValidatorPlugIn.java:234) at org.apache.struts.validator.ValidatorPlugIn.init(ValidatorPlugIn.java:165) at org.apache.struts.action.ActionServlet.initApplicationPlugIns(ActionServlet.java:983) at org.apache.struts.action.ActionServlet.init(ActionServlet.java:450) at javax.servlet.GenericServlet.init(GenericServlet.java) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:918) We have tried deploying the struts-validator example from the same nightly build. At least it's more consistent - it fails in each combination of browser server. Seems like a fault. Is this enough to help track it down? Anything else we can do? Cheers, Mike -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
