[jira] Updated: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
[ https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey updated OPENJPA-132: Fix Version/s: 0.9.7 java.lang.NoSuchMethodError for entity with ID of type java.sql.Date Key: OPENJPA-132 URL: https://issues.apache.org/jira/browse/OPENJPA-132 Project: OpenJPA Issue Type: Bug Components: kernel Reporter: Michael Dick Fix For: 0.9.7 Opening JIRA report to track the following problem (posted to development forum http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html) I'm getting the following exception when I try to fetch an entity with a java.sql.Date as the id : java.lang.NoSuchMethodError: org.apache.openjpa.util.DateId.getId()Ljava/sql/Date; at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java) at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java) at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118) at org.apache.openjpa.kernel.StateManagerImpl.initialize (StateManagerImpl.java:247) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252) at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108) at org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54) at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743) at org.apache.openjpa.kernel.DelegatingBroker.find (DelegatingBroker.java:169) at org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346) at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25) 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:585) at junit.framework.TestCase.runTest(TestCase.java:154) . . . It's coming from the generated bytecode which expects there to be a getId method that returns the same type of the Id, however java.sql.Date is using the same ID class as java.util.Date. Do we need a separate class for java.sql.Date? Responses from Patrick and Craig follow. The consensus so far is to provide ID separate classes for java.sql.Date and java.util.Date. It looks like we either need a separate type for java.sql.Date (and presumably java.sql.Timestamp), or we need to change the logic to accept a getId() method that returns a type that is assignable from the id field's type. -Patrick It's probably cleaner if we have separate classes for the different types. That is, have the getId method in the new org.apache.openjpa.util.SQLDateId return the proper type (java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not really the same as java.util.Date. -Craig FTR, I think that I prefer separate classes as well; it's clearer, and avoids any ambiguity with other subclasses in the future. -Patrick -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
[ https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey updated OPENJPA-132: Priority: Minor (was: Major) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date Key: OPENJPA-132 URL: https://issues.apache.org/jira/browse/OPENJPA-132 Project: OpenJPA Issue Type: Bug Components: kernel Reporter: Michael Dick Priority: Minor Fix For: 0.9.7 Opening JIRA report to track the following problem (posted to development forum http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html) I'm getting the following exception when I try to fetch an entity with a java.sql.Date as the id : java.lang.NoSuchMethodError: org.apache.openjpa.util.DateId.getId()Ljava/sql/Date; at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java) at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java) at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118) at org.apache.openjpa.kernel.StateManagerImpl.initialize (StateManagerImpl.java:247) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252) at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108) at org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54) at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743) at org.apache.openjpa.kernel.DelegatingBroker.find (DelegatingBroker.java:169) at org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346) at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25) 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:585) at junit.framework.TestCase.runTest(TestCase.java:154) . . . It's coming from the generated bytecode which expects there to be a getId method that returns the same type of the Id, however java.sql.Date is using the same ID class as java.util.Date. Do we need a separate class for java.sql.Date? Responses from Patrick and Craig follow. The consensus so far is to provide ID separate classes for java.sql.Date and java.util.Date. It looks like we either need a separate type for java.sql.Date (and presumably java.sql.Timestamp), or we need to change the logic to accept a getId() method that returns a type that is assignable from the id field's type. -Patrick It's probably cleaner if we have separate classes for the different types. That is, have the getId method in the new org.apache.openjpa.util.SQLDateId return the proper type (java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not really the same as java.util.Date. -Craig FTR, I think that I prefer separate classes as well; it's clearer, and avoids any ambiguity with other subclasses in the future. -Patrick -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.