[
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.
