You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Michael Dick (JIRA)" <ji...@apache.org> on 2007/02/07 23:42:05 UTC
[jira] Created: (OPENJPA-132) java.lang.NoSuchMethodError for
entity with ID of type java.sql.Date
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
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] Commented: (OPENJPA-132) java.lang.NoSuchMethodError for
entity with ID of type java.sql.Date
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482448 ]
Michael Dick commented on OPENJPA-132:
--------------------------------------
I'm fine using Abe's patch. The patch I submitted was just focussed on java.sql.Date, not the other java.sql classes. A simpler fix which adds more function is usually a good thing.
> 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
>
> Attachments: OpenJPA-132.patch.txt
>
>
> 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
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ 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] Commented: (OPENJPA-132) java.lang.NoSuchMethodError for
entity with ID of type java.sql.Date
Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482462 ]
Kevin Sutter commented on OPENJPA-132:
--------------------------------------
Abe,
Can you post your patch so that we can see how the two approaches differ? Thanks.
Kevin
> 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
>
> Attachments: OpenJPA-132.patch.txt
>
>
> 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] Commented: (OPENJPA-132) java.lang.NoSuchMethodError for
entity with ID of type java.sql.Date
Posted by "Abe White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482259 ]
Abe White commented on OPENJPA-132:
-----------------------------------
I have a fix ready to commit that consists of about 6 lines of enhancer code to account for Date subclasses when using DateId, just as we account for Object subclasses when using ObjectId. The fix avoids the new type constant, new identity class, and all the additional "case" statements for SQL dates in the patch proposed by Michael Dick. Additionally, the fix should work with java.sql.Time and java.sql.Timestamp too; Michael's fix will not. I believe this is a simpler, better solution. I also have a test case for SQL date id's ready to commit; we can use it with either my patch or Michael's. I will hold off on committing until we resolve whose patch to use.
> 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
>
> Attachments: OpenJPA-132.patch.txt
>
>
> 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] Commented: (OPENJPA-132) java.lang.NoSuchMethodError for
entity with ID of type java.sql.Date
Posted by "Abe White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482484 ]
Abe White commented on OPENJPA-132:
-----------------------------------
Sorry Kevin; I didn't see your comment before committing. As my resolution comment states, though, I can back my fix out if we decide we don't like it.
> 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
>
> Attachments: OpenJPA-132.patch.txt
>
>
> 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] Resolved: (OPENJPA-132) java.lang.NoSuchMethodError for
entity with ID of type java.sql.Date
Posted by "Abe White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Abe White resolved OPENJPA-132.
-------------------------------
Resolution: Fixed
Fixed in SVN revision 520522. We can back out if we decide to use an alternative fix strategy in the future.
> 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
>
> Attachments: OpenJPA-132.patch.txt
>
>
> 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
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (OPENJPA-132) java.lang.NoSuchMethodError for
entity with ID of type java.sql.Date
Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Dick updated OPENJPA-132:
---------------------------------
Attachment: OpenJPA-132.patch.txt
Attaching a patch.
The patch includes a new Id class for java.sql.Date and the appropriate hooks so that if will be used.
I chose to move the SQL_DATE constant from JavaSQLTypes to its superclass JavaTypes. The constant for java.sql.Date needed to be visible to the classes in openjpa-kernel and I didn't see a reason to have define two constants.
The remainder of the changes are fairly straightforward whenever there is special processing for java.util.Date I did the same thing for java.sql.Date.
I'll attach testcases separately, this is probably a big enough patch file to review and the tests need a little cleaning up.
> 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
>
> Attachments: OpenJPA-132.patch.txt
>
>
> 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.