I agree it is not a release stopper
I actually don't think it is just the constants, although it clearly is
related to the yearMonthDuration. E.g. the following 2 variations on the
failing tests still fail with the same NPEs
@Test public void nv_add_22() { testAdd("'P1Y1M'^^xsd:yearMonthDuration",
"'PT4H'^^xsd:dayTimeDuration", "'P1Y1MT4H'^^xsd:duration" ) ; }
@Test public void nv_sub_22() { testSub("'P2Y3M'^^xsd:yearMonthDuration",
"'P1Y2M'^^xsd:yearMonthDuration", "'P1Y1M'^^xsd:yearMonthDuration" ) ; }
It seems that duration arithmetic which involves xsd:yearMonthDuration is
causing trouble unless it happens with a dateTime. E.g. the test
@Test public void nv_add_24() { testAdd(
"'2000-01-01T00:00:00Z'^^xsd:dateTime",
"'P1Y1M'^^xsd:yearMonthDuration",
"'2001-02-01T00:00:00Z'^^xsd:dateTime") ; }
seems to succeed.
I can look at filing a defect with the JRE folks, but if this is outside
XSD requirements for durations, I doubt they'll do anything about it. Is
there a reason Jena permits this behavior?
Simon
From:
Andy Seaborne <[email protected]>
To:
Simon Helsen/Toronto/IBM@IBMCA
Cc:
[email protected]
Date:
06/12/2012 07:02 AM
Subject:
ARQ / duration test failure.
> Trying a single checkout I get the revision number 1349027. I run into
> the same ARQ problem (attached log file again) at first. However, I
> checked and I was using IBM's JRE 7 (*) - I also tried with IBM's JRE 6
> and the same effect. I then tried with Sun's JRE 7 (**) and things
> worked. That is not good of course. I understand this is an experimental
> feature, so perhaps it won't affect us, but it would be good to
> understand why there is a difference here.
tl;dr
I don't think this is a release stopper.
There are too many things elsewhere, unrelated, that have been fixed and
this is a localised problem (I hope!).
I tried: Sun Java 6 and the test pass:
java.runtime.name=OpenJDK Runtime Environment
java.vm.name=OpenJDK 64-Bit Server VM
java.runtime.version=1.6.0_24-b24
os.version=3.2.0-24-generic
java.version=1.6.0_24
I don't understand the relation of Sun and IBM JREs: the stacktrace has:
sun.reflect.NativeMethodAccessorImpl
in it.
org.apache.xerces.jaxp.datatype.AbstractDurationImpl.addDuration
Does the IBM JRE have an endorsed Xerces (it used to).
I wonder if the problem is not the operation itself at all, but the
setting up the constants.
The test is outside the strict XSD requirements for durations by one
reading: the test is a skew addition of yearMonth to a dayTime:
"'P1Y'^^xsd:yearMonthDuration" + "'PT4H'^^xsd:dayTimeDuration"
The test is supposed to pin down behaviour outside the strict spec.
I didn't understand what was meant to happen in this case so I went with
how the (Sun, java7) JRE hands it and it does add the quantities. The
values here are chosen so that they do not make it complicated - adding
26H to a yearMonth is complicated.
But NPE is not right outcome even if the XML processor is not accepting
this combination.
(Simon - I'll assume you'll deal with the report to the IBM JRE team)
> (Side question: when the single build fails because of a junit, it stops
> the rest - is there a way to continue?)
Not directly as far as I know because modules depend on previous ones.
You may be able to build+install with -DskipTests then run tests in a
module.
> I did see the issue with tdbloader before as well, but it didn't write
> anything in the log file and I had wrongly assumed that it was only a
> consequence of the problem with TS_Factory.
I fixed that (TS_Factory) I hope yesterday, leaving the tdbloader3 to be
looked at.
Andy
