On 12/30/21 5:35 PM, Andreas Beeker wrote:
Hi,
I've activated the POI rule set for forbidden APIs locally and there are
several locations popping up which are related to this.
I currently don't know yet on how to fix this, but my idea would be
either ...
a) to use the XmlOptions somehow to set the default timezone (and
locale) for dates - the goal is to avoid ThreadLocals. Or ...
b) for literals without timezone, we try to use the system/local timezone
As we do a) in POI - I would prefer this. And to minimize confusion, I
would raise the version to 6.0.0 and don't provide a j.u.Date and JSR
310 support in parallel if we choose JSR 310.
I noticed that the test was recently updated, but it is just checking
the offset of the current timezone and asserting for the 1999 or 2000
year. IMHO the test should be changing the current Timezone temporally
(for two or mote timezones) and not running one of two different
branches of code depending on the test environment.
By the way the internal use of java.time.Date instances is still a
problem, because on that test asserting for the year on a GDate is gives
the wrong year.
GDate gdate = ((XmlDate) res[0]).getGDateValue();
assertEquals(gdate.getYear(), 2000);
Test that using `export TZ=US/Eastern`
I will add a JIRA for this problem in order to continue the discussion
there.
Regarding the XPath plugins, I guess XmlCursor usage is more performant
- if you need a kind of plugin support again, we can work something out.
Currently I don't need the plugin, since I don't use anymore XMLBeans'
XPath support. I fond and that time weird that JXPath wasn't supported
at that time. I didn't want another XPath processor like Saxon, because
Apache Commons JXPath was already one in my application. I even remember
offering my service provider implementation but sadly got no response (a
lot of time ago)
Andi
---------------------------------------------------------------------
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]
