[
https://issues.apache.org/jira/browse/OPENJPA-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109509#comment-18109509
]
ASF subversion and git services commented on OPENJPA-2968:
----------------------------------------------------------
Commit 618a7b6594a0334fb884c6a802e9e8b5be890dbd in openjpa's branch
refs/heads/OPENJPA-2968 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=618a7b659 ]
[OPENJPA-2968] Do not swallow failures around IdClass primary key values
The @IdClass extraction and reconstruction paths added for the JPA 2.4.1.3
example 2b case caught every exception and continued: on write the primary
key columns were filled with nulls, on read the field was left null, so a
corrupt identity could be persisted or loaded without any trace. Both paths
now raise a StoreException naming the field, the id class and the mapping,
with the original failure chained, and a null id class value on the write
path is logged as a warning.
The columns are also no longer paired with the id class fields by
Class.getDeclaredFields() order, which the JVM does not guarantee. Where
every column names its target through referencedColumnName the fields are
matched by that name; the declaration order remains only as the fallback
for mappings that provide no name.
TestDerivedIdEx2c covers the ordering: its id class declares the fields in
the order opposite to the join columns, so a find() misses on the previous
code and succeeds now.
> 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)
