just checked and it is legal even in jpa 2.1. can be a bug in eclipse link or a setup issue.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2015-12-10 21:32 GMT+01:00 Karl Kildén <[email protected]>: > Thanks guys, > > the ticket: https://issues.apache.org/jira/browse/BATCHEE-87 > > Seems like a very odd spec change. > > On 10 December 2015 at 00:01, Romain Manni-Bucau <[email protected]> > wrote: > >> +1 >> >> Also tempted to check jpa dpec and open an issue since it is a big >> regression forbidden by EE spec. >> Le 9 déc. 2015 23:27, "Mark Struberg" <[email protected]> a écrit : >> >>> Indeed we should change this to java.util.Date. >>> >>> Imo the format in the DB should not change. Can you plz create a jira >>> issue for it? >>> >>> txs and LieGrue, >>> strub >>> >>> >>> >>> > Am 09.12.2015 um 21:48 schrieb Karl Kildén <[email protected]>: >>> > >>> > Hello, >>> > >>> > JobExecutionEntity is afaik not a regal entity because it maps >>> TemporalType to a java.sql.* (Timestamp). I think java.sql.* was legal at >>> one point in JPA but not anymore. >>> > >>> > The javadoc for Java EE 6 and Java EE 7 says this about TemporalType: >>> "Type used to indicate a specific mapping of java.util.Date or >>> java.util.Calendar." >>> > >>> > I tried a fancy scanning option from openejb that would hand the found >>> entities to jpa and suddenly eclipselink blew up because of that entity. >>> > >>> > Cheers / Karl >>> >>> >
