You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2012/06/12 13:00:58 UTC
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
Re: ARQ / duration test failure.
Posted by Andy Seaborne <an...@apache.org>.
On 12/06/12 16:13, Simon Helsen wrote:
> 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?
It's within the Java contract.
Note that the Java contract states that NPE is thrown iff the argument
is null. Otherwise the correct exception is IllegalStateException.
So NPE means NodevalueOps.additionNV
nv2.getDuration()
is null which track back to
"'PT4H'^^xsd:dayTimeDuration"
parses to a null duration on IBM and a Duration object on Sun.
That is from
Duration duration = xmlDatatypeFactory.newDuration(lex) ;
in NodeValue and hence DatatypeFactory.newInstance() is returning a
DatatypeFactory that can't parse PT4H as a dayTimeDuration. But then it
should throw IllegalArgumentException or UnsupportedOperationException.
Null is not a legal return value.
Given the way derived types work in XML,
Note the point of NPE is in xerces and the test set the Jena-shipped
version of Xerces so the versions of xerces are different and one has
been fixed if there is an endorsed jars. Otherwise, it is the inputs
being different hence DatatypeFactory or a under-java JVM bug, which is
unlikely.
Andy
>
> Simon
Re: ARQ / duration test failure.
Posted by Simon Helsen <sh...@ca.ibm.com>.
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 <an...@apache.org>
To:
Simon Helsen/Toronto/IBM@IBMCA
Cc:
dev@jena.apache.org
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