Oki, it should be rather easy to fix. Do we have a ticket for it already? Then I try to work on it tomorrow and ship a new VOTE.
Txs all for testing and finding this glitch! LieGrue, strub > Am 09.04.2019 um 20:39 schrieb Romain Manni-Bucau <[email protected]>: > > Mark, I tend to think it can be a blocker, criteria API looks broken even > in not spring data apps with some generic querying capabilities and I didnt > even check primefaces. > > What's the cost of a release these days - never did one on openjpa. If two > mvn commands I'm tempted to relaunch it straight, if a week I can agree > with your proposal. > > Wdyt? > > Le mar. 9 avr. 2019 à 20:33, Mark Struberg <[email protected]> a > écrit : > >> Hi Michael! >> >> I'd still move forward and fix this in a follow up release which we will >> ship soon. >> Is this ok for you? >> Can you please file a ticket so it doesn't get lost? >> >> LieGrue, >> strub >> >>> Am 09.04.2019 um 16:20 schrieb Michael Wiles <[email protected]>: >>> >>> I use Spring DAta extensively and am a big fan of openjpa so I want them >> to >>> place nice... >>> >>> I can't upgrade the 3.1 until this issue is fixed as basically, as far >> as I >>> can tell, any parameterised call via spring data does not work. >>> >>> Not sure it's the right place to discuss this but the way I see it the >>> ParameterExpressionImpl ( >>> >> https://github.com/apache/openjpa/blob/master/openjpa-persistence/src/main/java/org/apache/openjpa/persistence/criteria/ParameterExpressionImpl.java >> ) >>> has acquired a hashCode and equals with this release - >>> >> https://github.com/apache/openjpa/commit/0e4ec5b392b978c4515b26c60e485f2b610de94f#diff-e357856846fb8b88f15c08e60891cc35 >>> and >>> this is the code of the problem with spring data. >>> >>> Now what's happening is that the compile is called - and this is called >>> before the parameter expression has a value. All hashcode calcs are done >>> and stuff is added to a set. >>> >>> Then later on the value for the parameter is set. This causes changes to >>> the hashCode and equals, resulting in the problem that I'm seeing. >>> >>> Now I apologise if I'm completely out of line but I'm wondering why the >>> value is included in the hashCode and equals of a Parameter as surely a >>> value is a "runtime" concept and it not necessarily available at compile >>> time. >>> >>> Now the hashCode and equals were added for good reason I assume, and >>> furthermore, the value is included in the hashCode/equals also for good >>> reason. But we arguably need a mechanism to view the parameter purely >> from >>> a metadata point of view (which is I think what we need here) as well as >>> from a metadata+value point of view. >>> >>> But I do wonder why the ParamterExpressionImpl does include the value in >>> the hashCode and equals. My gut feel is that it's not necessary. >>> >>> Relevant stack traces: first time hashCode is called - at this point the >>> value is not specified in the ParameterExpressionImpl. Notice that the >>> CriteriaQueryImpl.compile kicks this off. >>> >>> >> org.apache.openjpa.persistence.criteria.ParameterExpressionImpl<T>.hashCode() >>> line: 154 >>> java.util.HashMap<K,V>.hash(java.lang.Object) line: 338 >>> >> java.util.LinkedHashMap<K,V>(java.util.HashMap<K,V>).containsKey(java.lang.Object) >>> line: 595 >>> org.apache.openjpa.lib.util.OrderedMap<K,V>.containsKey(java.lang.Object) >>> line: 70 >>> >> org.apache.openjpa.persistence.criteria.CriteriaQueryImpl<T>.registerParameter(org.apache.openjpa.persistence.criteria.ParameterExpressionImpl<?>) >>> line: 227 >>> >> org.apache.openjpa.persistence.criteria.CriteriaExpressionVisitor$ParameterVisitor.enter(org.apache.openjpa.persistence.criteria.CriteriaExpression) >>> line: 106 >>> >> org.apache.openjpa.persistence.criteria.Expressions.acceptVisit(org.apache.openjpa.persistence.criteria.CriteriaExpressionVisitor, >>> org.apache.openjpa.persistence.criteria.CriteriaExpression, >>> javax.persistence.criteria.Expression<?>...) line: 106 >>> >> org.apache.openjpa.persistence.criteria.ParameterExpressionImpl<T>(org.apache.openjpa.persistence.criteria.SelectionImpl<X>).acceptVisit(org.apache.openjpa.persistence.criteria.CriteriaExpressionVisitor) >>> line: 156 >>> >> org.apache.openjpa.persistence.criteria.Expressions.visitChildren(org.apache.openjpa.persistence.criteria.CriteriaExpressionVisitor, >>> javax.persistence.criteria.Expression<?>...) line: 121 >>> >> org.apache.openjpa.persistence.criteria.Expressions.acceptVisit(org.apache.openjpa.persistence.criteria.CriteriaExpressionVisitor, >>> org.apache.openjpa.persistence.criteria.CriteriaExpression, >>> javax.persistence.criteria.Expression<?>...) line: 108 >>> >> org.apache.openjpa.persistence.criteria.Expressions$Equal(org.apache.openjpa.persistence.criteria.Expressions$BinaryLogicalExpression).acceptVisit(org.apache.openjpa.persistence.criteria.CriteriaExpressionVisitor) >>> line: 278 >>> >> org.apache.openjpa.persistence.criteria.CriteriaQueryImpl<T>.collectParameters(org.apache.openjpa.persistence.criteria.CriteriaExpressionVisitor) >>> line: 681 >>> *org.apache.openjpa.persistence.criteria.CriteriaQueryImpl<T>.compile() >>> line: 672 * >>> >> org.apache.openjpa.persistence.EntityManagerImpl.createQuery(javax.persistence.criteria.CriteriaQuery<T>) >>> line: 1898 >>> >>> Then the error I get, occurs here - in >> org.apache.openjpa.kernel.QueryImpl >>> >>> protected void assertParameters(StoreQuery q, StoreQuery.Executor ex, >> Map >>> params) { >>> if (!q.requiresParameterDeclarations()) >>> return; >>> >>> OrderedMap<Object,Class<?>> paramTypes = >>> ex.getOrderedParameterTypes(q); >>> * for (Object actual : params.keySet()) {* >>> * if (!paramTypes.containsKey(actual))* >>> throw new UserException(_loc.get("unbound-params", >>> actual, paramTypes.keySet())); >>> } >>> for (Object expected : paramTypes.keySet()) { >>> if (!params.containsKey(expected)) >>> throw new UserException(_loc.get("unbound-params", >>> expected, paramTypes.keySet())); >>> } >>> >>> for (Entry<Object, Class<?>> entry : paramTypes.entrySet()) { >>> if (entry.getValue().isPrimitive() >>> && params.get(entry.getKey()) == null) >>> throw new UserException(_loc.get("null-primitive-param", >>> entry.getKey())); >>> } >>> } >>> >>> The error occurs in the bold stuff. >>> >>> And the fundamental reason as far as I can tell is that the paramtypes >> map >>> was populated when the value was set and then the *actual* reference in >>> this code has the value set... >>> >>> Iow, getOrderedParameterTypes returns the map created before the value >> was >>> set and the params.keySet has parameterExpressionImpls that have their >>> values set. >>> >>> And you know what happens when you use a hashMap and you change the >>> hashCode after you've populated the hashmap. >>> >>> Error stack trace: >>> at >> org.apache.openjpa.kernel.QueryImpl.assertParameters(QueryImpl.java:1849) >>> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:905) >>> at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:843) >>> at >>> >> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:601) >>> at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:297) >>> at >>> >> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:314) >>> at >>> >> org.apache.openjpa.persistence.QueryImpl.getSingleResult(QueryImpl.java:343) >>> 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:498) >>> at org.springframework.orm.jpa.SharedEntityManagerCreat >>> >>> On Mon, 8 Apr 2019 at 23:24, Romain Manni-Bucau <[email protected]> >>> wrote: >>> >>>> Yep, same thought >>>> >>>> No worries, we can always delay a bit the end of the vote to be sure of >> the >>>> quality we deliver >>>> >>>> Le lun. 8 avr. 2019 à 23:13, Jonathan Gallimore < >>>> [email protected]> a écrit : >>>> >>>>> At the moment, I believe its a spring-data thing rather than an OpenEJB >>>>> thing. I'll try and come up with an actual test, but it'll likely be >>>>> tomorrow morning. Hope that's ok. >>>>> >>>>> Jon >>>>> >>>>> On Mon, Apr 8, 2019 at 10:08 PM Romain Manni-Bucau < >>>> [email protected]> >>>>> wrote: >>>>> >>>>>> IMHO if we break spring data it is a blocker, if we break openejb >> layer >>>>> it >>>>>> is not since fixable with the upgrade. >>>>>> >>>>>> Le lun. 8 avr. 2019 à 23:05, Jonathan Gallimore < >>>>>> [email protected]> a écrit : >>>>>> >>>>>>> Removing the equals() and hashcode() methods added on >>>>>>> ParameterExpressionImpl here: >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> https://github.com/apache/openjpa/commit/0e4ec5b392b978c4515b26c60e485f2b610de94f#diff-e357856846fb8b88f15c08e60891cc35 >>>>>>> enables >>>>>>> the test I mentioned to pass. It seems that _boundsParam.get() here: >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> https://github.com/apache/openjpa/blob/master/openjpa-persistence/src/main/java/org/apache/openjpa/persistence/AbstractQuery.java#L81 >>>>>>> fails >>>>>>> with these equals()/hashcode() methods. >>>>>>> >>>>>>> Will see if I can fix and send a patch. I'm not sure if this issue >>>>> would >>>>>> be >>>>>>> considered to be a release blocker or not. >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> On Mon, Apr 8, 2019 at 11:25 AM Jonathan Gallimore < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> I get a single test failure on the TomEE side with this release - >>>>>>>> specifically org.superbiz.dynamic.DynamicUserDaoTest in >>>>>>>> examples/spring-proxy-data. I'll take a look during the day. >>>>> Otherwise, >>>>>>>> I'm +1. Thanks for the new release! >>>>>>>> >>>>>>>> Jon >>>>>>>> >>>>>>>> On Sun, Apr 7, 2019 at 3:14 PM Maxim Solodovnik < >>>>> [email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> Thanks for this release! >>>>>>>>> >>>>>>>>> On Sun, 7 Apr 2019 at 17:29, Francesco Chicchiriccò < >>>>>>> [email protected]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 2019-04-06 14:52 Mark Struberg wrote: >>>>>>>>>>> hi folks! >>>>>>>>>>> >>>>>>>>>>> We have fixed tons of enhancements and bugs in OpenJPA for our >>>>>> 3.1.0 >>>>>>>>>>> release. >>>>>>>>>>> One of the main improvements is to move to a native JavaEE8 >>>>> level >>>>>> - >>>>>>>>>>> JPA-2.2. >>>>>>>>>>> Please note that we implemented many JPA-2.2 features but not >>>>> all >>>>>>> yet. >>>>>>>>>>> We will work towards implementing the rest of the missing 2.2 >>>>>> stuff >>>>>>> in >>>>>>>>>>> the next bugfix releases. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Here are the fixed tickets: >>>>>>>>>>> >>>>>>>>>>> Sub-task >>>>>>>>>>> >>>>>>>>>>> • [OPENJPA-2710] - Create and update to >>>>>> geronimo-jpa_2.2_spec >>>>>>>>>>> Bug >>>>>>>>>>> >>>>>>>>>>> • [OPENJPA-1993] - Deadlock Potential with ORM XML >>>>>> Processing >>>>>>>>>>> • [OPENJPA-2555] - Timestamp precision from manual >>>> schema >>>>>> not >>>>>>>>>>> respected >>>>>>>>>>> • [OPENJPA-2567] - TINY/MEDIUM/LONG TEXT fields for >>>> MySQL >>>>>> and >>>>>>>>> MariaDB >>>>>>>>>>> are not supported >>>>>>>>>>> • [OPENJPA-2673] - Table is not created in openjpa >>>>>>>>> 3.0.0-SNAPSHOT and >>>>>>>>>>> OSGi >>>>>>>>>>> • [OPENJPA-2704] - The openjpa.jdbc.Schema no longer >>>>>> overrides >>>>>>>>> orm.xml >>>>>>>>>>> default >>>>>>>>>>> • [OPENJPA-2733] - Subquery parameters are incorrectly >>>>>>> assigned >>>>>>>>>>> • [OPENJPA-2742] - SchemaTool fails with MySQL >>>>>>>>>>> • [OPENJPA-2746] - OpenJPA Karaf feature is not complete >>>>>>>>>>> • [OPENJPA-2756] - PostgreSQL requires escaping of >>>> search >>>>>>>>> strings in >>>>>>>>>>> all versions >>>>>>>>>>> • [OPENJPA-2757] - upgrade to xbean-asm7 to support >>>> Java11 >>>>>>>>>>> • [OPENJPA-2761] - problem inserting more than 4000 >>>>>> charcters >>>>>>> in >>>>>>>>>>> oracle XMLTYPE column >>>>>>>>>>> • [OPENJPA-2764] - Map path expression tests behave >>>> random >>>>>>>>>>> • [OPENJPA-2768] - XMLStore SAXParser doesn't >>>> distinguish >>>>>>>>> between >>>>>>>>>>> element and extent >>>>>>>>>>> • [OPENJPA-2770] - false boolean literal doesn't work >>>>>>>>>>> • [OPENJPA-2771] - It seems like h2 'unlimited' is not >>>>>> "LIMIT >>>>>>>>> 0" but >>>>>>>>>>> rather "LIMIT -1" >>>>>>>>>>> • [OPENJPA-2772] - list of h2 reserved words is >>>> incomplete >>>>>>>>>>> • [OPENJPA-2777] - Indices specified using >>>>>>>>> javax.persistence.Index >>>>>>>>>>> annotation are not being created >>>>>>>>>>> • [OPENJPA-2780] - ReverseMappingTool does not generate >>>>>>>>> @Enumerated >>>>>>>>>>> annotation >>>>>>>>>>> • [OPENJPA-2781] - OpenJPA need internet connection to >>>>> read >>>>>>> the >>>>>>>>>>> persistence.xml >>>>>>>>>>> Improvement >>>>>>>>>>> >>>>>>>>>>> • [OPENJPA-2745] - Clean up try-catch implementation for >>>>>>>>> DB2Dictionary >>>>>>>>>>> • [OPENJPA-2747] - Upgrade to JPA 2.2 and use >>>>>>>>> javax.persistence-api >>>>>>>>>>> spec >>>>>>>>>>> • [OPENJPA-2748] - commons-collections should be updated >>>>> to >>>>>>> most >>>>>>>>>>> recent version >>>>>>>>>>> • [OPENJPA-2750] - commons-dbcp need to be updated to >>>> most >>>>>>>>> recent >>>>>>>>>>> version >>>>>>>>>>> • [OPENJPA-2751] - Code clean-up should be performed >>>>>>>>>>> • [OPENJPA-2752] - More libraries can be updated >>>>>>>>>>> • [OPENJPA-2753] - Create profiles to start various >>>>>> databases >>>>>>>>> via >>>>>>>>>>> Docker >>>>>>>>>>> • [OPENJPA-2755] - support MySQL DATETIME and TIMESTAMP >>>>>>>>> fractions >>>>>>>>>>> (milliseconds, nanos) >>>>>>>>>>> • [OPENJPA-2773] - set minIdle to > 0 in >>>>>> DBCPDriverDataSource >>>>>>>>>>> • [OPENJPA-2775] - hsqldb doesn't support NullTable to >>>>>>> retrieve >>>>>>>>> meta >>>>>>>>>>> information >>>>>>>>>>> Task >>>>>>>>>>> >>>>>>>>>>> • [OPENJPA-2744] - commons-pool should be updated to >>>> most >>>>>>> recent >>>>>>>>>>> version >>>>>>>>>>> • [OPENJPA-2754] - update to latest dbcp and verify >>>> moving >>>>>>> from >>>>>>>>>>> maxActive to maxTotal >>>>>>>>>>> • [OPENJPA-2758] - JPA 2.2 compliance >>>>>>>>>>> Dependency upgrade >>>>>>>>>>> >>>>>>>>>>> • [OPENJPA-2784] - update docs before our release >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The staging repository is at: >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> https://repository.apache.org/content/repositories/orgapacheopenjpa-1005/ >>>>>>>>>>> >>>>>>>>>>> The source release is at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> https://repository.apache.org/content/repositories/orgapacheopenjpa-1005/org/apache/openjpa/openjpa-parent/3.1.0/ >>>>>>>>>>> sha1 is 1aea7cfff20c3a5fed57fb41fb1fcd4784b999ae >>>>>>>>>>> >>>>>>>>>>> I've pushed the release branch to my github repo >>>>>>>>>>> https://github.com/struberg/openjpa/tree/release-3.1.0 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please VOTE: >>>>>>>>>>> >>>>>>>>>>> [+1] yeah, ship it! >>>>>>>>>>> [+0] meh, don't care >>>>>>>>>>> [-1] nah, because ${showstopper} >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> ..and special thanks to Mark, for his enduring effort! >>>>>>>>>> Regards. >>>>>>>>>> -- >>>>>>>>>> Francesco Chicchiriccò >>>>>>>>>> >>>>>>>>>> Tirasa - Open Source Excellence >>>>>>>>>> http://www.tirasa.net/ >>>>>>>>>> >>>>>>>>>> Member at The Apache Software Foundation >>>>>>>>>> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail >>>>>>>>>> http://home.apache.org/~ilgrosso/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> WBR >>>>>>>>> Maxim aka solomax >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> see my blog: >>> http://analysis102.blogspot.com >>> http://audiblethoughts.blogspot.com >>> http://outsideofficehours.blogspot.com >> >>
