[
https://issues.apache.org/jira/browse/OPENJPA-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110027#comment-18110027
]
ASF subversion and git services commented on OPENJPA-2968:
----------------------------------------------------------
Commit 66b630b6669f0d66e42c325f87825361412f01fc in openjpa's branch
refs/heads/OPENJPA-2968 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=66b630b66 ]
[OPENJPA-2968] Import java.lang.reflect.Field and brace the new blocks
Review feedback: import Field and Modifier instead of naming them fully
qualified, and give the if/else and loop bodies added by this change
braces.
> IdClass paths swallow exceptions and rely on field order
> --------------------------------------------------------
>
> Key: OPENJPA-2968
> URL: https://issues.apache.org/jira/browse/OPENJPA-2968
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
> Affects Versions: 4.2.0
> Reporter: Maxim Solodovnik
> Assignee: Richard Zowalla
> Priority: Major
> Fix For: 4.2.0
>
>
> Discussion thread:
> https://github.com/apache/openjpa/pull/144#discussion_r3683003006
> **(medium)** The IdClass reconstruction/extraction paths `catch (Exception)`
> and silently continue (here the field stays null; in `toDataStoreValue` at
> line 227 the PK columns get nulls written). Swallowing exceptions around
> primary-key values risks silently persisting/loading corrupt identities - at
> minimum a warn log, arguably a StoreException. Also `getInstanceFields` (line
> 448) maps IdClass fields to columns by `getDeclaredFields()` order, which the
> JVM does not guarantee - matching by name would be safer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
