[jira] Assigned: (JDO-263) TestArrayCollections: Field "org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.ArrayOfObject1" is declared as a reference type (interface/Object) but no implementation class
[ http://issues.apache.org/jira/browse/JDO-263?page=all ] Andy Jefferson reassigned JDO-263: -- Assign To: Michelle Caisse (was: Andy Jefferson) Changed JPOX to support this "element-type" attribute. You now have test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)java.lang.NullPointerException [java] at java.lang.System.arraycopy(Native Method) [java] at java.util.Vector.copyInto(Vector.java:166) [java] at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.setValues(TestArrayCollections.java:134) [java] at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.runTest(TestArrayCollections.java:96) [java] at org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.test(TestArrayCollections.java:69) > TestArrayCollections: Field > "org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.ArrayOfObject1" is > declared as a reference type (interface/Object) but no implementation classes > of "java.lang.Object" have been found! > -- > > Key: JDO-263 > URL: http://issues.apache.org/jira/browse/JDO-263 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Michelle Caisse > Assignee: Michelle Caisse > > test(org.apache.jdo.tck.models.fieldtypes.TestArrayCollections)javax.jdo.JDOUserException: > Field "org.apache.jdo.tck.pc.fieldtypes.ArrayCollections.ArrayOfObject1" is > declared as a reference type (interface/Object) but no implementation classes > of "java.lang.Object" have been found! > at > org.jpox.metadata.MetaDataUtils.getImplementationNamesForReferenceField(MetaDataUtils.java:594) > at > org.jpox.store.rdbms.table.ColumnCreator.createColumnsForReferenceField(ColumnCreator.java:184) > at > org.jpox.store.rdbms.table.ColumnCreator.createColumnsForField(ColumnCreator.java:296) > at > org.jpox.store.rdbms.table.ColumnCreator.createColumns(ColumnCreator.java:95) > at org.jpox.store.rdbms.table.ArrayTable.initialize(ArrayTable.java:83) > at > org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:2404) > at > org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2033) > at > org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:1893) > at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:479) > at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:493) > at > org.jpox.store.rdbms.RDBMSManager.getDatastoreClass(RDBMSManager.java:766) > at > org.jpox.state.StateManagerImpl.populateStrategyFields(StateManagerImpl.java:781) > at org.jpox.state.StateManagerImpl.(StateManagerImpl.java:584) > at > org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1076) > at > org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1131) > at > org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.runTest(TestArrayCollections.java:93) > at > org.apache.jdo.tck.models.fieldtypes.TestArrayCollections.test(TestArrayCollections.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) > at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (JDO-206) JDOQL test NotEquals comparing floating point numbers
[ http://issues.apache.org/jira/browse/JDO-206?page=all ] Michael Bouschen resolved JDO-206: -- Resolution: Fixed Fixed with revision 358029. > JDOQL test NotEquals comparing floating point numbers > - > > Key: JDO-206 > URL: http://issues.apache.org/jira/browse/JDO-206 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Andy Jefferson > Assignee: Michael Bouschen > Attachments: JDO-206.patch, JDO-206.patch2 > > The current TCK test (carried over from JDO 1.0) for NotEquals, uses != > operator on floating point numbers. This is not a good practice, and is > unreliable. Its probably the case that the Equals test uses == on the same > content, which also is not a good idea (as noted in the latest spec). These > tests need reviewing and a reliable alternate strategy adopting -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JDO-241) JPOX returns wrong query result for non-extent queries.
[
http://issues.apache.org/jira/browse/JDO-241?page=comments#action_12360939 ]
Michael Bouschen commented on JDO-241:
--
I checked in the patch (see revision 358033).
The test using a memory collection still fails, because the query does not
return the expected result. The memory collection used as query candidates
includes duplicates and since it is not a distinct query, the duplicates should
be included in the query result.
> JPOX returns wrong query result for non-extent queries.
> ---
>
> Key: JDO-241
> URL: http://issues.apache.org/jira/browse/JDO-241
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Michael Watzek
> Assignee: Erik Bengtson
> Attachments: JDO-241.patch
>
> Test case DistinctCandidateInstances fails because JPOX returns an empty
> collection for the query below. The query uses a candidate collection.
> 14:22:46,781 (main) DEBUG [org.apache.jdo.tck] - Executing JDO query: SELECT
> FROM org.apache.jdo.tck.pc.company.Person
> 14:22:46,796 (main) DEBUG [org.apache.jdo.tck] - Query result: []
> 14:22:46,812 (main) DEBUG [org.apache.jdo.tck] - Wrong query result:
> expected: [FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
> {work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
> FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
> {work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
> PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
> {work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
> PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
> {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
> FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
> {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0),
> FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
> {work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
> FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
> {work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
> PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
> {work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
> PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
> {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
> FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
> {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0)]
> got: []
> 14:22:46,812 (main) INFO [org.apache.jdo.tck] - Exception during setUp or
> runtest:
> junit.framework.AssertionFailedError: Assertion A14.6.9-2
> (DistintCandidateInstances) failed:
> Wrong query result:
> expected: [FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
> {work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
> FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
> {work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
> PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
> {work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
> PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
> {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
> FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
> {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0),
> FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
> {work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
> FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
> {work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
> PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
> {work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
> PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
> {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
> FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
> {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0)]
> got: []
> at junit.framework.Assert.fail(Assert.java:47)
> at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546)
> at org.apache.jdo.tck.query.QueryTest.queryFailed(QueryTest.java:500)
> at
> org.apache.jdo.tck.query.QueryTest.checkQueryResultWithoutOrder(QueryTest.java:485)
> at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1189)
> at
> org.apache.jdo.tck.query.QueryTest.executeJDOQuery(QueryTest.java:1057)
> at
> org.apache.jdo.tck.query.result.DistinctCandidateInstances.testCollectionQueries(DistinctCandidateInstan
[jira] Commented: (JDO-194) JPOX does not support implicit variables.
[ http://issues.apache.org/jira/browse/JDO-194?page=comments#action_12360940 ] Michael Bouschen commented on JDO-194: -- Yesterday (Dec 19) I updated my workspace and ran all the tests. I see the same errors (NoClassDefFoundError) as Michael Watzek described above. > JPOX does not support implicit variables. > - > > Key: JDO-194 > URL: http://issues.apache.org/jira/browse/JDO-194 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Michael Watzek > Assignee: Erik Bengtson > > JPOX throws an exception executing queries having implicit parameters (see > below). The bug may be reproduced executing test case > org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields. > Query: SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE > team.contains(employee) & employee.firstname == 'emp1First' > org.jpox.store.exceptions.NoSuchPersistentFieldException: Field "employee" > does not exist in org.apache.jdo.tck.pc.company.Person or is not persistent > at > org.jpox.store.rdbms.table.ClassTable.getFieldMapping(ClassTable.java:1790) > at > org.jpox.store.expression.TableExpression.newFieldExpression(TableExpression.java:183) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:1534) > at > org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1299) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) > at > org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1346) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileQueryStatement(JDOQLQuery.java:891) > at org.jpox.store.query.JDOQLQuery.compile(JDOQLQuery.java:569) > at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:639) > at org.jpox.store.query.Query.executeWithMap(Query.java:907) > at org.jpox.store.query.Query.executeWithArray(Query.java:887) > at org.jpox.store.query.Query.execute(Query.java:819) > at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:706) > at > org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:625) > at > org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:601) > at > org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields.testPositive(VariablesAndFields.java:148) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAcce
[jira] Commented: (JDO-194) JPOX does not support implicit variables.
[ http://issues.apache.org/jira/browse/JDO-194?page=comments#action_12360941 ] Andy Jefferson commented on JDO-194: And I have a clean checkout of about 30 mins ago and still get no errors whatsoever on those tests. Perhaps something in your setup ? I use Linux and Maven 1.0.2. You use Windows don't you Michael ? The issue is more than likely some windows case-sensitivity or file separator issue. > JPOX does not support implicit variables. > - > > Key: JDO-194 > URL: http://issues.apache.org/jira/browse/JDO-194 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Michael Watzek > Assignee: Erik Bengtson > > JPOX throws an exception executing queries having implicit parameters (see > below). The bug may be reproduced executing test case > org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields. > Query: SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE > team.contains(employee) & employee.firstname == 'emp1First' > org.jpox.store.exceptions.NoSuchPersistentFieldException: Field "employee" > does not exist in org.apache.jdo.tck.pc.company.Person or is not persistent > at > org.jpox.store.rdbms.table.ClassTable.getFieldMapping(ClassTable.java:1790) > at > org.jpox.store.expression.TableExpression.newFieldExpression(TableExpression.java:183) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:1534) > at > org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1299) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) > at > org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1346) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileQueryStatement(JDOQLQuery.java:891) > at org.jpox.store.query.JDOQLQuery.compile(JDOQLQuery.java:569) > at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:639) > at org.jpox.store.query.Query.executeWithMap(Query.java:907) > at org.jpox.store.query.Query.executeWithArray(Query.java:887) > at org.jpox.store.query.Query.execute(Query.java:819) > at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:706) > at > org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:625) > at > org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:601) > at > org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields.testPositive(Vari
[jira] Commented: (JDO-244) JPOX generates illegal SQL for having clauses using COUNT.
[ http://issues.apache.org/jira/browse/JDO-244?page=comments#action_12360944 ] Craig Russell commented on JDO-244: --- I don't think the ordering is needed on the first query. Otherwise, looks good. > JPOX generates illegal SQL for having clauses using COUNT. > -- > > Key: JDO-244 > URL: http://issues.apache.org/jira/browse/JDO-244 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Michael Watzek > Assignee: Erik Bengtson > Attachments: JDO-244.patch > > JPOX generates illegal SQL for the query below. The having clause specifies > an aggregate COUNT. > 14:22:50,906 (main) DEBUG [org.apache.jdo.tck] - Executing API query: SELECT > department, SUM(salary) FROM org.apache.jdo.tck.pc.company.Employee GROUP BY > department HAVING COUNT(department.employees) > 0 > 14:22:51,031 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > javax.jdo.JDODataStoreException: Error executing JDOQL query "SELECT > THIS.DEPARTMENT,SUM(THIS.SALARY) FROM applicationidentity0.PERSONS THIS LEFT > OUTER JOIN applicationidentity0.DEPARTMENTS THIS_DEPARTMENT_EMPLOYEES ON > THIS.DEPARTMENT = THIS_DEPARTMENT_EMPLOYEES.ID WHERE THIS.DISCRIMINATOR = ? > OR THIS.DISCRIMINATOR = ? OR THIS.DISCRIMINATOR = ? GROUP BY THIS.DEPARTMENT > HAVING COUNT() > 0" : Syntax error: Encountered ")" at line 1, column 324. > ERROR 42X01: Syntax error: Encountered ")" at line 1, column 324. > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(Unknown > Source) > at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) > at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) > at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.(Unknown > Source) > at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown > Source) > at > com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:190) > at org.jpox.store.StatementText.prepareStatement(StatementText.java:199) > at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:678) > at org.jpox.store.query.Query.executeWithMap(Query.java:966) > at org.jpox.store.query.Query.executeWithArray(Query.java:939) > at org.jpox.store.query.Query.execute(Query.java:862) > at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1151) > at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1029) > at > org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:966) > at > org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:946) > at org.apache.jdo.tck.query.result.Having.testPositive(Having.java:110) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.textui.TestRunner.doRun(TestRunner.java:116) > at junit.textui.TestRunner.doRun(TestRunner.java:109) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120) > at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95) > . > at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:747) > at org.jpox.store.query.Query.executeWithMap(Query.java:966) > at org.jpox.store.query.Query.executeWithArray(Query.java:939) > at org.jpox.store.query.Query.execute(Query.java:862) > at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1151)
[jira] Commented: (JDO-241) JPOX returns wrong query result for non-extent queries.
[
http://issues.apache.org/jira/browse/JDO-241?page=comments#action_12360949 ]
Andy Jefferson commented on JDO-241:
H. You call setCandidates() and pass in the same object twice and so you
expect the query to return dups ? Sounds unintuitive to me. The query specifies
that some object is a candidate for being returned (twice) and that, to me at
least, means that we allow the selected candidates be part of the result - and
the object is part of the result. The basic query says return all Person
objects. I see "candidates" as a further filter only ... not some way of saying
"return me the same thing twice, or three times depending on how many times I
put it in my candidates list".
> JPOX returns wrong query result for non-extent queries.
> ---
>
> Key: JDO-241
> URL: http://issues.apache.org/jira/browse/JDO-241
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Michael Watzek
> Assignee: Erik Bengtson
> Attachments: JDO-241.patch
>
> Test case DistinctCandidateInstances fails because JPOX returns an empty
> collection for the query below. The query uses a candidate collection.
> 14:22:46,781 (main) DEBUG [org.apache.jdo.tck] - Executing JDO query: SELECT
> FROM org.apache.jdo.tck.pc.company.Person
> 14:22:46,796 (main) DEBUG [org.apache.jdo.tck] - Query result: []
> 14:22:46,812 (main) DEBUG [org.apache.jdo.tck] - Wrong query result:
> expected: [FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
> {work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
> FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
> {work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
> PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
> {work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
> PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
> {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
> FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
> {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0),
> FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
> {work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
> FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
> {work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
> PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
> {work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
> PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
> {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
> FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
> {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0)]
> got: []
> 14:22:46,812 (main) INFO [org.apache.jdo.tck] - Exception during setUp or
> runtest:
> junit.framework.AssertionFailedError: Assertion A14.6.9-2
> (DistintCandidateInstances) failed:
> Wrong query result:
> expected: [FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
> {work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
> FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
> {work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
> PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
> {work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
> PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
> {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
> FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
> {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0),
> FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
> {work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
> FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
> {work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
> PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
> {work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
> PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
> {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
> FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
> {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0)]
> got: []
> at junit.framework.Assert.fail(Assert.java:47)
> at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546)
> at org.apache.jdo.tck.query.QueryTest.queryFailed(QueryTest.java:500)
> at
> org.apache.jdo.tck.query.QueryTest.checkQueryResultWithoutOrder(QueryTest.java:485)
> at org
[jira] Commented: (JDO-241) JPOX returns wrong query result for non-extent queries.
[
http://issues.apache.org/jira/browse/JDO-241?page=comments#action_12360950 ]
Craig Russell commented on JDO-241:
---
The spec is clear on this issue (which is specifically being tested). Queries
against a collection return duplicates unless the distinct keyword is used.
A14.6.9-2 [Queries against an extent always consider only distinct candidate
instances, regardless of whether distinct is specified. Queries against a
collection might contain duplicate candidate instances; the distinct keyword
removes duplicates from the candidate collection in this case.]
> JPOX returns wrong query result for non-extent queries.
> ---
>
> Key: JDO-241
> URL: http://issues.apache.org/jira/browse/JDO-241
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Michael Watzek
> Assignee: Erik Bengtson
> Attachments: JDO-241.patch
>
> Test case DistinctCandidateInstances fails because JPOX returns an empty
> collection for the query below. The query uses a candidate collection.
> 14:22:46,781 (main) DEBUG [org.apache.jdo.tck] - Executing JDO query: SELECT
> FROM org.apache.jdo.tck.pc.company.Person
> 14:22:46,796 (main) DEBUG [org.apache.jdo.tck] - Query result: []
> 14:22:46,812 (main) DEBUG [org.apache.jdo.tck] - Wrong query result:
> expected: [FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
> {work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
> FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
> {work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
> PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
> {work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
> PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
> {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
> FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
> {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0),
> FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
> {work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
> FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
> {work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
> PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
> {work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
> PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
> {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
> FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
> {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0)]
> got: []
> 14:22:46,812 (main) INFO [org.apache.jdo.tck] - Exception during setUp or
> runtest:
> junit.framework.AssertionFailedError: Assertion A14.6.9-2
> (DistintCandidateInstances) failed:
> Wrong query result:
> expected: [FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
> {work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
> FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
> {work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
> PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
> {work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
> PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
> {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
> FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
> {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0),
> FullTimeEmployee(1, emp1Last, emp1First, born 10/Jun/1970, phone
> {work=123456-1, home=}, hired 1/Jan/1999, weeklyhours 40.0, $2.0),
> FullTimeEmployee(2, emp2Last, emp2First, born 22/Dec/1975, phone
> {work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $1.0),
> PartTimeEmployee(3, emp3Last, emp3First, born 5/Sep/1972, phone
> {work=123456-3, home=}, hired 15/Aug/2002, weeklyhours 19.0, $15000.0),
> PartTimeEmployee(4, emp4Last, emp4First, born 6/Sep/1973, phone
> {work=124456-3, home=3343}, hired 15/Apr/2001, weeklyhours 0.0, $13000.0),
> FullTimeEmployee(5, emp5Last, emp5First, born 5/Jul/1962, phone
> {work=126456-3, home=3363}, hired 15/Aug/1998, weeklyhours 0.0, $45000.0)]
> got: []
> at junit.framework.Assert.fail(Assert.java:47)
> at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546)
> at org.apache.jdo.tck.query.QueryTest.queryFailed(QueryTest.java:500)
> at
> org.apache.jdo.tck.query.QueryTest.checkQueryResultWithoutOrder(QueryTest.java:485)
> at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1189)
> at
> org.apache.jdo.tck.query.QueryTest.executeJDOQuery(Query
[jira] Commented: (JDO-194) JPOX does not support implicit variables.
[ http://issues.apache.org/jira/browse/JDO-194?page=comments#action_12360951 ] Michael Bouschen commented on JDO-194: -- Interesting! Yes, I'm using Windows. I think it has to do with queries using a variable with the same name as a class (modulo case). The above JDOQL query SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE team.contains(employee) & employee.firstname == 'emp1First' defines an implicit variable called employee where Employee is the base name of the candidate class. It does not matter whether the variable is defined implicitly or explicitly. The problem disappears if I change the variable name to e.g. 'emp'. The method names in the stack trace suggest that JPOX tries to resolve the identifier 'employee' as class name. Is that the case. Which occurrence of 'employee' is causing the problem, the contains argument or the left hand side of the equals comparison? > JPOX does not support implicit variables. > - > > Key: JDO-194 > URL: http://issues.apache.org/jira/browse/JDO-194 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Michael Watzek > Assignee: Erik Bengtson > > JPOX throws an exception executing queries having implicit parameters (see > below). The bug may be reproduced executing test case > org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields. > Query: SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE > team.contains(employee) & employee.firstname == 'emp1First' > org.jpox.store.exceptions.NoSuchPersistentFieldException: Field "employee" > does not exist in org.apache.jdo.tck.pc.company.Person or is not persistent > at > org.jpox.store.rdbms.table.ClassTable.getFieldMapping(ClassTable.java:1790) > at > org.jpox.store.expression.TableExpression.newFieldExpression(TableExpression.java:183) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:1534) > at > org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1299) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) > at > org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1346) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileQueryStatement(JDOQLQuery.java:891) > at org.jpox.store.query.JDOQLQuery.compile(JDOQLQuery.java:569) > at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:639) > at org.jpox.store.query.Quer
JIRA issues
JIRA has a nice feature to track issues and releases. Issues can be flagged when resolved with the release in which the issue is shipped. Once the release ships, the issue can be closed. Once the issue is closed, it can no longer be assigned to a release without reopening it.So, in order to track which issues belong to which releases, JIRA issues must not be closed until the release ships. For JDO, this means that no JIRA issues should be closed yet. [I've reopened issues against the api20 project specifically for the purpose of assigning them to the beta release.]Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (JDO-194) JPOX does not support implicit variables.
[ http://issues.apache.org/jira/browse/JDO-194?page=comments#action_12360959 ] Andy Jefferson commented on JDO-194: JPOX would have to check for whether something is a class or not before falling back to "implicit variable". As for which variable "employee" is the issue I've no idea ... but then I don't see the issue so can't debug it. The stack trace line numbers provided by Michael above don't correspond to what I have in JPOX CVS either. Provide a valid stack trace using the most recent JPOX build, and just the part like the following at org.jpox.util.Imports.resolveClassDeclaration(Imports.java:152) at org.jpox.store.query.Query.resolveClassDeclaration(Query.java:844) at org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:1993) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1650) Without valid line numbers I can't do a thing. > JPOX does not support implicit variables. > - > > Key: JDO-194 > URL: http://issues.apache.org/jira/browse/JDO-194 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Michael Watzek > Assignee: Erik Bengtson > > JPOX throws an exception executing queries having implicit parameters (see > below). The bug may be reproduced executing test case > org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields. > Query: SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE > team.contains(employee) & employee.firstname == 'emp1First' > org.jpox.store.exceptions.NoSuchPersistentFieldException: Field "employee" > does not exist in org.apache.jdo.tck.pc.company.Person or is not persistent > at > org.jpox.store.rdbms.table.ClassTable.getFieldMapping(ClassTable.java:1790) > at > org.jpox.store.expression.TableExpression.newFieldExpression(TableExpression.java:183) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:1534) > at > org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1299) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) > at > org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1346) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileQueryStatement(JDOQLQuery.java:891) > at org.jpox.store.query.JDOQLQuery.compile(JDOQLQuery.java:569) > at org.jpox.store.query.JDOQLQuery.performExecute(JDOQLQuery.java:639) > at org.jpox.store.query.Query.
[VOTE] Issue 139: Add attribute field-type to element field
Javadogs,This will resolve an issue in the TCK where fields of type Object cannot be stored because there is no standard way to map them, even if usage restricts the type of instances assigned to the field. This is an issue in particular for relational mappings of classes that use interfaces or Object in the class definition. This proposal would allow more specific field type to be specified at deployment time compared to compile time. For example, a field of type Object could be specified in the jdo metadata as containing only instances of type SimpleClass.18.14 ELEMENT fieldThe field-type attribute is used to specify a more restrictive type than the field definition in the class. This might be required in order to map the field to the datastore. To be portable, specify the name of a single type that is itself able to be mapped to the datastore (e.g. a field of type Object can specify field-type=”Integer”). Other values for this attribute are not defined. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Negative [VOTE]: Issue 146: TCK : ResultClassRequirements.testNegative
Javadogs,Please reply if you do not agree with this change.CraigI've reviewed the spec and I'm inclined to agree with Andy about the intent, and with both Andy and Michael about the exact wording of the specification, which does appear to disallow the negative test case as written. Although there is some ambiguity that I think we should clean up regardless.It seems that the following queries have the same semantics but due to the way the spec is written, have very different behavior. The first query disallows the use of the (long, String) constructor whereas the second query could use set or put methods if there were no corresponding constructor (even though a constructor appears to be called for by the use of the "new" keyword). As an aside, the first query seems to be more readable...SELECT personid, lastnameINTO org.apache.jdo.tck.query.result.classes.LongStringFROM org.apache.jdo.tck.pc.company.FullTimeEmployeeSELECT new org.apache.jdo.tck.query.result.classes.LongString (personid, lastname)FROM org.apache.jdo.tck.pc.company.FullTimeEmployeeI remember having the discussion about constructors when we talked about the constructor specification in the setResult versus the constructor in the setResultClass. I do not remember why we chose to restrict the case discussed in the bug report. It could simply be my bad transcription of the discussion.To remedy this, I propose changing the spec to move the setResultClass phrase. This change implements Andy's suggestion below, making the above queries semantically and behaviorally equivalent.A constructor of a result class specified in the setResult method will be used if the results specification matches the parameters of the constructor by position and type. If more than one constructor satisfies the requirements, the JDO implementation chooses one of them. If no constructor satisfies the results requirements, or if the result class is specified via the setResultClass method, the following requirements apply:A constructor of a result class specified in the constructor _expression_ of the setResult method or in the setResultClass method will be used if the results specification matches the parameters of the constructor by position and type. If more than one constructor satisfies the requirements, the JDO implementation chooses one of them. If no constructor satisfies the results requirements, the following requirements apply:On Nov 23, 2005, at 10:45 AM, Andy Jefferson wrote: Hi Michael, SELECT personid, lastname INTOorg.apache.jdo.tck.query.result.classes.LongString FROMorg.apache.jdo.tck.pc.company.FullTimeEmployeeNow referring to 14.6.12, the impl needs to find a constructor taking theexpressions by position and type. It finds a constructorLongString(long,String) and so can use it to create a result object. Why isthis supposed to throw an exception exactly ? The query has an INTO clause specifying a result class. For thisreason, the constructor LongString(long, String) should not be chosen. OK, your test is following the "rules" in the latest spec to the letter :-).I prefer to look at it from a user viewpoint. "setResultClass" is the placewhere the vast majority of people will specify the result class. The specseemingly isn't allowing a user to provide a result class with the correctconstructor parameters and use that to construct the object. This is alimitation that I see no obvious reason for. Is there a reason ?IMHO, the sequence should be1. Use a constructor with the parameter positions/types.or2. Use a default constructor2a. public fields matching name and type2b. public set method matching name and type2c. public put(Object, Object) method-- Andy Craig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/jdo408 276-5638 mailto:[EMAIL PROTECTED]P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Negative [VOTE] Issue 149: Restrictions on Ordering expression used with Grouping
Javadogs,Please reply if you do not agree.CraigOn Dec 19, 2005, at 11:25 AM, Craig L Russell wrote:Javadogs,See JIRA issue JDO-243 http://issues.apache.org/jira/browse/JDO-243?page=allOrdering should have the same restrictions as for the Select clause. That is, if grouping is used, only expressions in the Grouping clause and aggregate expressions can be in the Ordering clause.The JDO implementation is not permitted to modify the Select clause, the Grouping clause, or the Ordering clause. These are user-visible and should not be changed by the implementation.However, the JDO implementation is required to construct valid SQL if the query is being used with a relational datastore. This means that the SQL SELECT might need to have expressions added to the user's Select clause to include expressions in the Grouping and Ordering clauses.Today in the specification there are restrictions on the expressions that can be used in the Select clause if there is a Grouping clause: Only expressions in the Grouping clause and aggregate expressions can be in the Select clause. A similar restriction is needed for the Ordering clause. Only expressions in the Grouping clause and aggregate expressions can be in the Ordering clause. Craig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/jdo408 276-5638 mailto:[EMAIL PROTECTED]P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Issue 150: Consistency requirements for relationships with mapped-by
Javadogs,In chapter "15.3 Relationship Mapping" of the spec, "changes to the field mapped via mapped-by are not reflected in the datastore".However, this conflicts with the text that follows: "... the column(s) will be changed during commit and will therefore be visible by both sides in the next transaction.".I believe that the second part is more important than the first part. Specifically, if the user makes a change to a persistent field, at flush or commit time it makes sense to me that the implementation should make sure that the change is flushed to the datastore. Further, the spec says that changes will be visible by both sides in the next transaction, which has implications for RetainValues.I think it's technically feasible for changes to either side to be reflected in the database, and for RetainValues to be handled consistently.If two relationships (one on each side of an association) are mapped to the same column, the field on only one side of the association needs to be explicitly mapped.The field on the other side of the relationship can be mapped simply by using the mapped-by attribute identifying the field on the side that defines the mapping. Regardless of which side changes the relationship, flush (whether done as part of commit or explicitly by the user) will modify the datastore to reflect the change. There is no further relationship implied by having both sides of the relationship map to the same database column(s). In particular, making a change to one side of the relationship does not imply any runtime behavior by the JDO implementation to change the other side of the relationship in memory prior to flush and will therefore be visible by both sides in the next transaction. If the RetainValues flag or DetachAllOnCommit is set to true, and the relationship field is loaded, then the implementation will change the field on the other side so it is visible after transaction completion.Conflicting changes to relationships cause a JDOUserException to be thrown at flush time. Conflicting changes include: adding a related instance with a single-valued mapped-by relationship field to more than one one-to-many collection relationshipsetting both sides of a one-to-one relationship such that they do not refer to each other Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (JDO-194) JPOX does not support implicit variables.
[ http://issues.apache.org/jira/browse/JDO-194?page=comments#action_12360994 ] Michael Bouschen commented on JDO-194: -- This is a part of the stack trace from todays run using the JPOX build available today: ... at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.jpox.JDOClassLoaderResolver.classOrNull(JDOClassLoaderResolver.java:449) at org.jpox.JDOClassLoaderResolver.classForName(JDOClassLoaderResolver.java:140) at org.jpox.util.Imports.resolveClassDeclaration(Imports.java:152) at org.jpox.store.query.Query.resolveClassDeclaration(Query.java:844) at org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:2019) at org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1676) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1624) at org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1605) ... Please let me know in case you need more. > JPOX does not support implicit variables. > - > > Key: JDO-194 > URL: http://issues.apache.org/jira/browse/JDO-194 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Michael Watzek > Assignee: Erik Bengtson > > JPOX throws an exception executing queries having implicit parameters (see > below). The bug may be reproduced executing test case > org.apache.jdo.tck.query.jdoql.variables.VariablesAndFields. > Query: SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE > team.contains(employee) & employee.firstname == 'emp1First' > org.jpox.store.exceptions.NoSuchPersistentFieldException: Field "employee" > does not exist in org.apache.jdo.tck.pc.company.Person or is not persistent > at > org.jpox.store.rdbms.table.ClassTable.getFieldMapping(ClassTable.java:1790) > at > org.jpox.store.expression.TableExpression.newFieldExpression(TableExpression.java:183) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileIdentifier(JDOQLQuery.java:1534) > at > org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1299) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) > at > org.jpox.store.query.JDOQLQuery$Compiler.compilePrimary(JDOQLQuery.java:1346) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpressionNotPlusMinus(JDOQLQuery.java:1245) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileUnaryExpression(JDOQLQuery.java:1226) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileMultiplicativeExpression(JDOQLQuery.java:1179) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAdditiveExpression(JDOQLQuery.java:1156) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileRelationalExpression(JDOQLQuery.java:1125) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileEqualityExpression(JDOQLQuery.java:1102) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileAndExpression(JDOQLQuery.java:1090) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExclusiveOrExpression(JDOQLQuery.java:1078) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileInclusiveOrExpression(JDOQLQuery.java:1066) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalAndExpression(JDOQLQuery.java:1054) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileConditionalOrExpression(JDOQLQuery.java:1036) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileExpression(JDOQLQuery.java:1013) > at > org.jpox.store.query.JDOQLQuery$Compiler.compileQueryStatement(JDOQLQuery.java:891) > at org.jpox.store.que
[jira] Created: (JDO-264) Fix issues in maven.xml preventing iut goals from running properly
Fix issues in maven.xml preventing iut goals from running properly -- Key: JDO-264 URL: http://issues.apache.org/jira/browse/JDO-264 Project: JDO Type: Bug Components: tck20 Reporter: Michelle Caisse Assigned to: Michelle Caisse maven.xml has not been properly tested on an implementation under test (iut). Test and fix any problems encountered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JDO-264) Fix issues in maven.xml preventing iut goals from running properly
[ http://issues.apache.org/jira/browse/JDO-264?page=comments#action_12361009 ] Michelle Caisse commented on JDO-264: - revision 358164 - Added connection pooling jars to project.class.path and removed reference implementation jars. Must now copy iut jars to iut_jars. > Fix issues in maven.xml preventing iut goals from running properly > -- > > Key: JDO-264 > URL: http://issues.apache.org/jira/browse/JDO-264 > Project: JDO > Type: Bug > Components: tck20 > Reporter: Michelle Caisse > Assignee: Michelle Caisse > > maven.xml has not been properly tested on an implementation under test (iut). > Test and fix any problems encountered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JDO-72) Test api.persistencemanager.OptimisticFailure hangs
[ http://issues.apache.org/jira/browse/JDO-72?page=comments#action_12361013
]
Craig Russell commented on JDO-72:
--
If you tell me what version strategs are supported by JPOX, I'll put the
version information into the metadata. There are four strategies documented,
all of them are required.
This might be a good opportunity for adding supportedOptions that tell which
strategies are supported.
> Test api.persistencemanager.OptimisticFailure hangs
> ---
>
> Key: JDO-72
> URL: http://issues.apache.org/jira/browse/JDO-72
> Project: JDO
> Type: Bug
> Components: tck20
> Environment: JPOX, Derby
> Reporter: Craig Russell
> Assignee: Erik Bengtson
>
> This test is designed to create conflicts in the database from two different
> JDO transactions. The changes in the cache must not be visible in the
> datastore or timeouts will occur. The exception here occurs when the second
> optimistic JDO transaction attempts to read a row that has been changed in
> the cache by the first optimistic JDO transaction.
> private void runTestOptimistic(PersistenceManager pm1,
>PersistenceManager pm2,
>PersistenceManager pm3) {
> if (!isOptimisticSupported()) {
>if (debug)
>logger.debug("OptimisticFailure tests not run; Optimistic not
> supported");
>return;
> }
> Transaction tx1 = pm1.currentTransaction();
> Transaction tx2 = pm2.currentTransaction();
> Transaction tx3 = pm3.currentTransaction();
> try {
>tx1.setOptimistic(true);
>tx2.setOptimistic(true);
>
>// create four instances to test
>tx1.begin();
>pm1.makePersistent(p1);
>pm1.makePersistent(p2);
>pm1.makePersistent(p3);
>pm1.makePersistent(p4);
>pm1.makePersistent(p5);
>p1oid = pm1.getObjectId(p1);
>p2oid = pm1.getObjectId(p2);
>p3oid = pm1.getObjectId(p3);
>p4oid = pm1.getObjectId(p4);
>p5oid = pm1.getObjectId(p5);
>tx1.commit();
>
>// update/delete the instances in tx1
>tx1.begin();
>PCPoint p1tx1 = (PCPoint)pm1.getObjectById(p1oid, true);
>PCPoint p2tx1 = (PCPoint)pm1.getObjectById(p2oid, true);
>PCPoint p3tx1 = (PCPoint)pm1.getObjectById(p3oid, true);
>PCPoint p4tx1 = (PCPoint)pm1.getObjectById(p4oid, true);
>p1tx1.setX(101);
>p2tx1.setX(201);
>pm1.deletePersistent(p3tx1);
>pm1.deletePersistent(p4tx1);
>
>// update/delete the instances in tx2
>tx2.begin();
> *** PCPoint p1tx2 = (PCPoint)pm2.getObjectById(p1oid, true); *** this is
> where the test hangs ***
>PCPoint p2tx2 = (PCPoint)pm2.getObjectById(p2oid, true);
>PCPoint p3tx2 = (PCPoint)pm2.getObjectById(p3oid, true);
>PCPoint p4tx2 = (PCPoint)pm2.getObjectById(p4oid, true);
>PCPoint p5tx2 = (PCPoint)pm2.getObjectById(p5oid, true);
>p1tx2.setX(102);
> // pm2.deletePersistent(p2tx2); // this should fail but succeeds
> due to an RI bug
>p3tx2.setX(202);
>pm2.deletePersistent(p4tx2);
>p5tx2.setX(502); // this change should not be committed
>Set expectedFailedObjects = new HashSet();
>expectedFailedObjects.add(p1tx2);
> // expectedFailedObjects.add(p2tx2);
>expectedFailedObjects.add(p3tx2);
>expectedFailedObjects.add(p4tx2);
>
>// commit tx1 (should succeed)
>tx1.commit();
>tx1 = null;
>
>// commit tx2 (should fail)
>try {
>tx2.commit();
>fail(ASSERTION_FAILED, "concurrent commit not detected");
>}
>catch (JDOOptimisticVerificationException ex) {
>// verify the correct information in the exception
> RUN OptimisticFailure.test[INFO] tck - Exception during setUp or runtest:
> PCPOINT.X,PCPOINT.Y,PCPOINT.ID FROM PCPOINT WHERE (PCPOINT.ID = ?)
> [java] NestedThrowables:
> [java] SQL Exception: A lock could not be obtained within the time
> requested>javax.jdo.JDODataStoreException: Fetch request failed: SELECT
> PCPOINT.X,PCPOINT.Y,PCPOINT.ID FROM PCPOINT WHERE (PCPOINT.ID = ?)
> [java] at
> org.jpox.store.rdbms.request.FetchRequest.execute(FetchRequest.java:195)
> [java] at
> org.jpox.store.rdbms.table.ClassTable.fetch(ClassTable.java:1739)
> [java] at org.jpox.store.StoreManager.fetch(StoreManager.java:665)
> [java] at
> org.jpox.state.StateManagerImpl.loadDFGFields(StateManagerImpl.java:1573)
>
Re: Issue 150: Consistency requirements for relationships with mapped-by
Wow, that's definitely great! 'Managed Bi-directional Relationship' feature is what I have been waiting for so long, though this proposal doesn't fully include MBR, it solved the problem in most pratical cases. --- Craig L Russell <[EMAIL PROTECTED]> wrote: > Javadogs, > > In chapter "15.3 Relationship Mapping" of the spec, > "changes to the > field mapped via mapped-by are not reflected in the > datastore". > > However, this conflicts with the text that follows: > > "... the column(s) will be changed during commit > and will therefore > be visible by both sides in the next transaction.". > > I believe that the second part is more important > than the first part. > Specifically, if the user makes a change to a > persistent field, at > flush or commit time it makes sense to me that the > implementation > should make sure that the change is flushed to the > datastore. > Further, the spec says that changes will be visible > by both sides in > the next transaction, which has implications for > RetainValues. > > I think it's technically feasible for changes to > either side to be > reflected in the database, and for RetainValues to > be handled > consistently. > > > If two relationships (one on each side of an > association) are mapped > to the same column, the field on only one side of > the association > needs to be explicitly mapped. > The field on the other side of the relationship can > be mapped simply > by using the mapped-by attribute identifying the > field on the side > that defines the mapping. Regardless of which side > changes the > relationship, flush (whether done as part of commit > or explicitly by > the user) will modify the datastore to reflect the > change. There is > no further relationship implied by having both sides > of the > relationship map to the same database column(s). In > particular, > making a change to one side of the relationship does > not imply any > runtime behavior by the JDO implementation to change > the other side > of the relationship in memory prior to flush and > will therefore be > visible by both sides in the next transaction. If > the RetainValues > flag or DetachAllOnCommit is set to true, and the > relationship field > is loaded, then the implementation will change the > field on the other > side so it is visible after transaction completion. > Conflicting changes to relationships cause a > JDOUserException to be > thrown at flush time. Conflicting changes include: > adding a related instance with a single-valued > mapped-by relationship > field to more than one one-to-many collection > relationship > setting both sides of a one-to-one relationship such > that they do not > refer to each other > > > > Craig Russell > Architect, Sun Java Enterprise System > http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
