These are notes I gathered from the last version of
the TCK I ran (not what I just got from Apache, but
maybe some of the problems remain, we'll see). These
are notes on the test source code itself. I'm not
looking for any feedback on this, jut thought I would
toss it out there.
Package: com.sun.jdotck.api.PersistenceManager
==============================================
[test class = GetObjectIdClass]
contains hardcoded reference to RI's OID class.
c1.getName().equals("com.sun.jdori.fostore.OID")
This causes non-RI to wrongly fail.
[test class =
ConcurrentPersistenceManagerSameClasses]
Does not properly cleanup PCPoint and PCRect
objects. COnsequently, if the
test is run more than once, it fails the second
time. The reason for
failure is because the "findPoint" method issues a
jdo query, and uses
the first object returned by the query's iterator.
However, there may
be multiple objects in the iterator. The test then
goes on to compare the
JAVA identity of said first object with the JAVA
identity of the object
made persistent earlier in the transaction. This
leads to a failure with
a message:
"Found PCPoint: 110, 120
Expected: 110, 120"
This test would be fixed by deleting all objects
matching the query BEFORE
doing the first insert, or by changing the test
comparison from JAVA
identity to 110==p11a.getX() && 120==p11a.getY()
[test = OneInstanceOfObjectPerPersistenceManager]
this test cannot be run twice in a row without
clearing the database. Query
findPoint (int x, int y) will simply find a point
from a previous run. Since
we're using datastore identity, the object
retrieved from the query will be
different since it has a different database pk.
this results in Failed.
"Assertion A5.4-2 failed; query results differ"
[test = RefreshSideEffects]
While not stricktly a bug, this test cannot be run
twice in a row from the
same JVM. This is because PersistenceCapable "n1"
is declared as static.
The second time the test is run,
"makePersistent(n1)" is called on a different
persistence manager, while n1 remains in the cache
of the first pm. This
is illegal. This problem also manifests itself in
all tests begining with
"Refresh".
Package: com.sun.jdotck.api.InstanceCallbacks
=============================================
[test class = CallingJdoPreClear]
in InstanceCallbackClass.jdoPreClear the following
line causes a
NullPointerException because children is null:
<code>
...
numberOfChildren[intValue] = children.size();
...
</code>
children is not in the default-fetch-group and
never gets loaded within the
transaction for the PC "primaryObj". The
"touchFields" method never touches
primaryObj.children, thus it remains
null, having been set null in the transition to
HOLLOW caused by the prior
commit. Because jdoPreClear is not modified by the
enhancer, children does
not get loaded when jdoPreClear is called and the
NullPointerException is
thrown. This could be fixed by modifying the
"instanceCallbacks.jdo" meta-
data to add default-fetch-group="true" for the
field 'children'.
package: com.sun.jdotck.models.company
=======================================
[test class = Company]
in constructor, parameter 'addr' is not assigned
to instance variable
'address'
<code>
address = address
</code>
should be changed to "this.address = addr;"
package: com.sun.jdotck.models.fieldtypes
=======================================
[test class = TestFieldsOfObject]
The default value for Object0 is null. When the
test forces garbage
collection via System.gc(), the PC is garbage
collected. When the PC is
materialized from the datastore on getObjectById,
a new instance of the PC
is constructed. Because Object0 is not persistent,
val assumes null default
value. This causes a null pointer exception when
!val.equals(startValue)
is evaluated. The solution is to properly set the
value of isPersistent[0]
to false. This test incorrectly has set
isPersistent[0] to true. If the
value of isPersistent[0] is set to false, the
offending block of code is
correctly skiped and the null pointer avoided.
The same error will be caused for several
non-persistent fields.
All of the following indexes of isPersistent
should be false, not true:
0,16,36,52,72,88,108,124
[test class = TestFieldsOfSimpleInterface]
The problem is identical to that of
TestFieldsOfObject.
All of the following indexes of isPersistent
should be false, not true:
0,16,36,52,72,88,108,124
[test class = TestCollectionCollections]
Should not use Vector, since application is not
required to support
Collection or Set unless they reference a
HashSet. Causes a
ClassCastException to be thrown.
package: com.sun.jdotck.models.inheritance
=======================================
[test class = NonpersistentSuperclass]
Any time a superclass field is referenced, I had
to modify the source to
cast the object to the concrete class containing
the field. For example,
c.floatE must be changed to
((TopNonPersistE)c).floatE, because the field
floatE is contained in uphierarchy class
TopNonPersistE. If I do not do this
a NoSuchMethodException is thrown from within the
enhanced class. I believe
this to be a bug in the reference enhancer. From
now on I'll call this
SUPERCLASS_ENHANCED_FIELD_BUG
Also, this test depends on restoreValues=true, but
does not setup
restoreValues to be true. I had to set
restoreValues=true in iut.properties.
[test class = FieldWithSameNameInSuperclass]
SUPERCLASS_ENHANCED_FIELD_BUG and
Enancer does not appear to be enhancing
FieldSameName4.n3 or
FieldSameName3.n1. In the case of
FieldSameName3.n1 this is correct because
FieldSameName2 declares
persistence-modifier="none" in metadata, so n1 should
not be persistent in FieldSameName3. But it does
look like FieldSameName4.n3
should be enhanced.
Mutators get/setIntH in FieldsSameName4 access
FieldsSameName4.n3, which
explains the messages printed by the test below.
However, the parts of
the test that say "intF should be ..." represent
an erroneus check against
non-enhanced field FieldsSameName3.n1. Since the
fiels is not enhanced, it
would not get restored.
"
Object reverted to transient after rollback.
Persistent attribute shortF is 25, it should be 394
Object reverted to transient after rollback.
Persistent attribute intH is 26, it should be -347600
Read object back after rollback. Persistent
attribute shortF is 6, it should be 258
Read object back after rollback. Persistent
attribute intH is 7, it should be -25
Read object back after rollback. Persistent
attribute shortF is 15, it should be 8
Read object back after rollback. Persistent
attribute intH is 16, it should be -603
"
[test class =
NonPersistentFieldsAreNonPersistentInSubclass]
SUPERCLASS_ENHANCED_FIELD_BUG
[test class =
TransactionalFieldsAreTransactionalInSubclasses]
SUPERCLASS_ENHANCED_FIELD_BUG
here is an example of the error produced by
SUPERCLASS_ENHANCED_FIELD_BUG
"Failed. Class linking error while trying to load
test class
`com.sun.jdotck.models.inheritance.TransactionalFieldsAreTransactionalInSubclasses':
java.lang.NoSuchMethodError:
com.sun.jdotck.models.inheritance.AllPersist4.jdoSetthirdObj(Lcom/sun/jdotck/models/inheritance/AllPersist4;Lcom/sun/jdotck/models/inheritance/AllPersist4;)V"
[test class =
PersistentFieldsArePersistentInSubClasses]
SUPERCLASS_ENHANCED_FIELD_BUG
For datastore identity, the AllPersist equals
method is broken.
Equals will fail with a ClassCastException if obj
is an
AllPersist. Basically this method cannot return
true unless *application*
identity is used! Since I am testing with
Datastore identity, both the equals
and hashcode methods should not be changes from
their defaults in Object.
Therefore I commented them out.
package: com.sun.jdotck.query.operators
=======================================
NOTE: None of these tests in this package passes
completely due to bogus
comparisons of floats to ints, etc. The spec
warns against doing such
comparisons, so I take these "failures" with a
grain of salt.
[test =
com.sun.jdotck.query.operators.BinaryAddition]
This tests is broken. the first thing it does in
execute an invalid filter,
which naturally throws an exception (which the
test is not coded to catch).
To get the test beyond the initial exception, I
commented out the bunk query.
This test also erroneously compares the characters
'o' and 'E' to the integer
1+8. It also erroneusly compares 1+8 to a very
large random integer value.
The error messages print nothing to indicate why
the test failed. I inserted
a print to show the error:
Executing test BinaryAddition() ...
Size = 1
Object is PrimitiveTypes(9)
Size = 1
Object is PrimitiveTypes(9)
Size = 1
Object is PrimitiveTypes(9)
Size = 1
Object is PrimitiveTypes(9)
error, Size = 0but expected size() = 0 for filter:
charNotNull == 1 + 8
Size = 1
Object is PrimitiveTypes(9)
Size = 1
Object is PrimitiveTypes(9)
Size = 1
Object is PrimitiveTypes(9)
Size = 1
Object is PrimitiveTypes(9)
Size = 1
Object is PrimitiveTypes(9)
Size = 1
Object is PrimitiveTypes(9)
error, Size = 0but expected size() = 0 for filter:
charNull == 1 + 8
Size = 1
Object is PrimitiveTypes(9)
Size = 1
Object is PrimitiveTypes(9)
Size = 1
Object is PrimitiveTypes(9)
error, Size = 0but expected size() = 0 for filter:
bigInteger == 1 + 8
[test =
com.sun.jdotck.query.operators.GreaterThanOrEqual]
MySql comparisons of BigInt broken when BigInt
represented as String.
Example: SELECT "-999999999999999999" =
-999999999999999999
returns 0. Should return 1 since MySQL supposed to
convert string to number
when one argument of arithmetic is number and
other is String.
This causes:
JDOQL GreaterThanOrEqual test returns wrong number
of instances with filter "fld_BigInteger >= value",
parameter "java.math.BigInteger value"
Expected 10 Got 9
ordering of String comparisons is not specified by
the spec.
MySQL: SELECT "JDO" >= "abcde" will return 1.
Therefore the
following should not be errors:
JDOQL GreaterThanOrEqual test returns incorrect
value with filter "value >= fld_String", parameter
"String value"
Retrieved value: abcde, with parameter value: JDO
JDOQL GreaterThanOrEqual test returns incorrect
value with filter "value >= fld_String", parameter
"String value"
Retrieved value: abcdef, with parameter value: JDO
JDOQL GreaterThanOrEqual test returns incorrect
value with filter "value >= fld_String", parameter
"String value"
Retrieved value: Java, with parameter value: JDO
JDOQL GreaterThanOrEqual test returns incorrect
value with filter "value >= fld_String", parameter
"String value"
Retrieved value: hello world, with parameter
value: JDO
JDOQL GreaterThanOrEqual test returns incorrect
value with filter "value >= fld_String", parameter
"String value"
Retrieved value: Java, with parameter value: JDO
JDOQL GreaterThanOrEqual test returns wrong number
of instances with filter "value >= fld_String",
parameter "String value"
Expected 2 Got 7
JDOQL GreaterThanOrEqual test returns wrong number
of instances with filter "fld_String >= value",
parameter "String value"
Expected 9 Got 4
JDOQL GreaterThanOrEqual test returns wrong number
of instances with filter "value.fld_String >=
fld_String", parameter
"com.sun.jdotck.models.fieldtypes.AllTypes value"
Expected 8 Got 2
JDOQL GreaterThanOrEqual test returns incorrect
value with filter "fld_String >= "Java""
Retrieved value: JDO has a very nice persistence
API, with parameter value: Java
JDOQL GreaterThanOrEqual test returns incorrect
value with filter "fld_String >= "Java""
Retrieved value: JDO, with parameter value: Java
JDOQL GreaterThanOrEqual test returns incorrect
value with filter "fld_String >= "Java""
Retrieved value: JDO is a breeze to use, with
parameter value: Java
JDOQL GreaterThanOrEqual test returns wrong number
of instances with filter "fld_BigInteger >= value",
parameter "java.math.BigInteger value"
Expected 10 Got 9
[test = com.sun.jdotck.query.operators.Equality]
The following fail:
<code>
run_intQuery(int_filterL, floatParameter, new
Float(Integer.MAX_VALUE), Integer.MAX_VALUE, 1);
run_intQuery(int_filterR, floatParameter, new
Float(Integer.MIN_VALUE), Integer.MIN_VALUE, 1);
</code>
This is because rounding of Integer.MaxValue and
Integer.MIN_VALUE. This is
expected. Don't try to compare floats to ints.
Same goes for BigInteger, int,
Long, etc. This test has many bogus comparisons.
[test =
com.sun.jdotck.query.operators.GreaterThan]
Bogus comparisons of floats to ints, String to
String, etc., fail due to
rounding.
[test = com.sun.jdotck.query.operators.LessThan]
Bogus comparisons of floats to ints, String to
String, etc., fail due to
rounding or DB ordering or string comparisons.
[test = com.sun.jdotck.query.operators.NotEquals]
Bogus comparisons of floats to ints, String to
String, etc., fail due to
rounding or DB ordering or string comparisons.
[test =
com.sun.jdotck.query.operators.LessThanOrEqual]
Bogus comparisons of floats to ints, String to
String, etc., fail due to
rounding or DB ordering or string comparisons.
package: com.sun.jdotck.query
=============================
[test =
ExecutingMultipleQueriesSimultaneouslyIsThreadSafe]
If this test executed a single query in each pm,
simultaneously this test would pass.
But, the same query is executed multiple times
inside a single transaction.
This causes deadlock, see explaination below. This
deadlock is unavoidable
even if the queries are ordered in the same
direction.
[test =
MultipleActiveQueryInstanceInSamePersistenceManagerExecutedSimultaneously]
This test does not, in fact, use the "same
persistence manager" for all the
queries as is implied by the name. In fact, it
uses a different pm for each
query, and naturally the queries deadlock as a
result of this. The deadlock
occurs because from different PM's, the same
sequence of the same query is
executed. PM A locks the rows in the RS. PM B's
query waits for PM A to
release the rows. PM A then queries the same rows
again, and deadlocks
because B has the next lock. There was a method
commented out
//pm = getThePM(pmf); This would have done what
the test purports to do.
It would have kept a static instance of the PM
that all the simultaneous
instances would use.
However, the test would then fail because all the
simultaneous
instances do a pm.currentTransaction.begin(). And
you can't call begin multiple
times on the same transaction. So generally, this
test is very screwed up and
difficult to even think of a way to make it work.
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
