openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Abe White (JIRA)" <>
Subject [jira] Commented: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
Date Mon, 19 Mar 2007 23:19:32 GMT


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:
>             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

> 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 (
>     at mikedd.entities.SqlDatePK.pcNewInstance(
>     at org.apache.openjpa.enhance.PCRegistry.newInstance(
>     at org.apache.openjpa.kernel.StateManagerImpl.initialize (
>     at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(
>     at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(
>     at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(
>     at org.apache.openjpa.kernel.ROPStoreManager.initialize(
>     at org.apache.openjpa.kernel.BrokerImpl.initialize (
>     at org.apache.openjpa.kernel.BrokerImpl.find(
>     at org.apache.openjpa.kernel.BrokerImpl.find(
>     at org.apache.openjpa.kernel.DelegatingBroker.find (
>     at org.apache.openjpa.persistence.EntityManagerImpl.find(
>     at mikedd.tests.TestSqlDateId.testFindAfterClear(
>     at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>     at java.lang.reflect.Method.invoke (
>     at junit.framework.TestCase.runTest(
>     . . .
> 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.

View raw message