| Hello,
I’m a big fan of Ramsey’s ERXTimeZoneDetector. I’m seeing occasional NPEs like this:
java.lang.NullPointerException: timeZone must not be set to null
at er.extensions.appserver.ERXSession.setTimeZone(ERXSession.java:810)
at er.extensions.components.ERXTimeZoneDetector.takeValuesFromRequest(ERXTimeZoneDetector.java:148)
at com.webobjects.appserver._private.WOComponentReference.takeValuesFromRequest(WOComponentReference.java:119)
ERXSession.setTimeZone() doesn’t like nulls, and that’s fair enough. It’s being called from here:
public void takeValuesFromRequest(WORequest request, WOContext context) { super.takeValuesFromRequest(request, context); if (shouldPostData() && request.formValueForKey(TIMEZONE_DATA_KEY) != null) { ... TimeZone tz = zoneWithRawOffset(rawOffset, dst, southern); session.setTimeZone(tz); } }
That is, when ERXTimeZoneDetector thinks it’s found the TimeZone, it calls setTimeZone(), except sometimes tz is null. In the resulting log output, ERXBasicBrowser is suggesting the culprit is usually IE 8, sometimes IE 9. I don’t know whether this is a legitimate app user, or someone browsing the login page, or a bot. I don’t currently have the facilities to try to reproduce this with IE.
I’m not sure how much I really care, but it would be nice to avoid the NPEs. Ramsey, what would your preference be for the behaviour of the component here if it reaches setTimeZone() but tz is null? Meanwhile, I might add some extra logging and… wait. It would be interesting to know what zoneString turned out to be, for example.
|