[
https://issues.apache.org/jira/browse/OPENJPA-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14544187#comment-14544187
]
Diogo Monteiro commented on OPENJPA-2386:
-----------------------------------------
Still keep getting the same problem with openjpa 2.4.0.
Here is the stack track:
<openjpa-2.4.0-r422266:1674604 nonfatal user error>
org.apache.openjpa.persistence.ArgumentException: The specified parameter of
type "class java.time.LocalDateTime" is not a valid query parameter.
at org.apache.openjpa.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1534)
at org.apache.openjpa.jdbc.sql.DBDictionary.setUnknown(DBDictionary.java:1462)
at org.apache.openjpa.jdbc.sql.SQLBuffer.setParameters(SQLBuffer.java:608)
at
org.apache.openjpa.jdbc.kernel.SQLStoreQuery$SQLExecutor.executeUpdate(SQLStoreQuery.java:163)
at org.apache.openjpa.kernel.QueryImpl.update(QueryImpl.java:1055)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:866)
at org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:903)
at org.apache.openjpa.kernel.DelegatingQuery.updateAll(DelegatingQuery.java:597)
at org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:370)
at
com.clouddynamics.heliotime.api.meter.helper.ResourceMeterQuery.stopMeter(ResourceMeterQuery.java:56)
at
com.clouddynamics.heliotime.api.meter.command.StartMeterCmd.create(StartMeterCmd.java:100)
at
com.clouddynamics.heliotime.api.meter.command.StartMeterCmd.execute(StartMeterCmd.java:85)
at com.clouddynamics.heliotime.api.BaseApi.execute(BaseApi.java:41)
at
com.clouddynamics.heliotime.api.meter.command.StartMeterCmd.restEndPoint(StartMeterCmd.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
> Support for JAVA 8
> ------------------
>
> Key: OPENJPA-2386
> URL: https://issues.apache.org/jira/browse/OPENJPA-2386
> Project: OpenJPA
> Issue Type: Improvement
> Components: build / infrastructure, Enhance, jpa
> Affects Versions: 2.3.0
> Reporter: Kevin Sutter
> Assignee: Rick Curtis
> Fix For: 2.2.3, 2.4.0
>
>
> A few different aspects exist for the support of Java 8. The first being
> tolerance of the Java 8 runtime. If OpenJPA and the application are built
> and enhanced with Java 7 (or Java 6), then will these class files execute in
> a Java 8 environment? My assumption is "yes" since this would be consistent
> with our initial experiences with Java 7. But, some testing will be required
> to verify this.
> The next aspect is the building of the application Entities with Java 8.
> Building and enhancing Java Entity class files with Java 8 looks to be
> hazardous... The first indication is that ASM doesn't seem to handle the
> Java 8 class file format. And, if ASM doesn't handle it, then I'm sure that
> Serp doesn't handle it either. Now, whether our use of ASM as a
> post-processor for Serp will suffice this time around, I have no idea.
> This brings back the question of dropping Serp support altogether and going
> the ASM route
> (http://openjpa.208410.n2.nabble.com/DISCUSS-Java7-and-Serp-td6951682.html).
> I know there's been some interest in this in the past.
> A longer-term aspect is when do we actually build OpenJPA with Java 8 and
> take advantage (exploit) of the new features. I think we have a long ways
> before we have to cross that hurdle. When we start developing JPA 2.1, we'll
> probably have to upgrade our build process to use Java 7. So, we're probably
> on the same type of cycle for Java 8 for building OpenJPA (when it's required
> by Java EE 8).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
