[Tools 2.0] Possible to change the default locale of DateTool after configure()

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

All,

I just spent an inordinate amount of time tracking-down a
date-formatting problem in one of our applications. The real root
cause of the problem was that some silly programmer did something like
this:

<element attribute="$dateFormat.format('MM/dd/yyyy',
$object.dateField)" />

That looked perfectly fine to me, but it was failing in one of our
environments. I added a bunch of debug code to the template to see
what in the world was happening. Something like this:

<!-- dateFormat = $dateFormat.class.name -->
<!-- dateField = $object.dateField of type
$object.dateField.class.name -->
<element attribute="$dateFormat.format('MM/dd/yyyy',
$object.dateField)" />


That quick debugging showed me that object.dateField was actually a
java.lang.String instead of a java.util.Date like ... everyone in
their right mind would have suspected.

Printing-out the value of the dateField field in both environments led
to very similar strings like "March 2, 2017 3:19:01 PM EST" for
example. In one environment, that was being re-formatted as "expected"
and in another environment, we were getting a literal
"$dateFormat.format('MM/dd/yyyy', $object.dateField)" string.

My expectation was that this wouldn't work in *any* environment and
that it was a miracle it had been working for as long as it had been.
But... why was this *one* environment not working, when all the others
were? Or, rather, what was so special about the *other* environments
that made this all work?

A quick dive into DateTool.format(String,Object,Locale,Timezone)
showed me that DateTool was doing us a big favor and parsing the
second argument (what should be a java.util.Date but was actually a
java.lang.String). DateTool uses an internal format and locale that it
inherits from its superclass that appear to only be settable at
configure()-time.

We have our dateFormat object configured like this:

<tools>
  <toolbox scope="application">
[...]
    <tool key="dateFormat"
class="org.apache.velocity.tools.generic.DateTool" />
[...]

So we should get the default locale which is Locale.getLocale(). On
all of our environments, the default locale should be either plain
"en" or en_US. Once the configure() call completes, it should not be
possible to change that default locale.

After much gnashing of teeth and hair-pulling, we found the problem:
in the one environment where things were *not* working, the
internally-maintained locale for the DateTool was zh_CN for some
reason. That meant that when we took a string like "March 2, 2017
3:19:01 PM EST" it could not be parsed, because zh_CN expects the
default format to look like "2017-3-2 13:19:01". The string-value
could not be parsed (as was successful in all our other environments)
and so the "date" couldn't be re-formatted into our preferred date forma
t.

I checked, and user.language=en and user.country=US for the JVM
process (confirmed by jinfo -sysprops). I also arranged for
Locale.getDefault() to be called and we got en_US as the default locale.

I believe the VelocityLayoutServlet we are using is only initialized a
single time, and only has a single toolbox, configured from the
configuration summarized above.

Can anyone give a scenario where DateTool's locale might be changed? I
don't see anywhere that the user's current (request) locale could
affect the locale of any lazily-constructed DateTool instances. Is
there maybe some kind of code-path that would cause the locale to change
?

Simply bouncing our service in this environment got everything back to
the expected state (and I've filed an irritated bug against the
component that is storing a date value as a java.lang.String), so we
are good to go. But I'm curious as to whether anyone can come up with
an explanation for how my service got into this state?

Any grasps at straws would be greatly appreciated.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYwH5FAAoJEBzwKT+lPKRYHdQP/1rTVI3jGPs2HaMz4WkSxGMr
gLeFukZ2HhE7rFUuYu65oUjtiAFmf3vg01rOlKqQ6IZQzz5Ys+tbMiP7ebAOpDFc
oC44N5XjY8NSadILmDIgW0rfkyP7suGb8TFDqzTnFwuSCTL1VDH4FFiPLq5vV22P
ofiCKws2SnymLvo4TcE7ITpT6aOtTQJiHCo3DGI6SxCk3/wUYGaDGUO//MLtZKQZ
Dluyod2rSEyrw24wKJaG7eXMAJwSp8VIasvkJ5f78LqU9e80J6j6NuYcXYJAckDz
93Z8zviGVFDktJKpKYoKPNIyi4Mxn2WXhMxMlPl17hcjKbu6OKZzNfOZqErFB57d
ty2lZefd+n+ATvr/7wc/UZl27DNQm09v7Z7oI7MFutEFl1sb67YcyFxCWOQQWZc7
Ffb6WH4vpltp1mv0hjvjRWOxy2TbSceDi+0c5m/o4cmQOAJjQlrF22LOyQzCVXxt
lcaHv8pxI9jha1duB4f7XgqsOMIOj43+6mgr407JFx++2+Nenxsb9qCtgYGB9g+7
6yBCTlIzChPzkWiWz0/FjVmkpknHuh4kUBF4kO2spNAwa71PCbkuOOv5u02gUWhg
UMbumEhlArbrg/O7hywdMxwKdSQixncUMXOAl8gG89i3c3/waBS7XKx9xdjGfZLd
koS+3sVlYZbdWgFMJHeT
=nW7w
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org