openjpa-dev mailing list archives

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


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