Skip to content

[OPENJPA-2953] Keep converter overrides out of shared embeddable and superclass meta - #200

Merged
cristof merged 1 commit into
masterfrom
OPENJPA-2953
Oct 6, 2026
Merged

cristof merged 1 commit into
masterfrom
OPENJPA-2953

Conversation

@rzo1

@rzo1 rzo1 commented Oct 5, 2026

Copy link
Copy Markdown
Contributor

A @Convert(attributeName=...) override was written into metadata shared between entities: for an embeddable it went to the repository-level ClassMetaData that every embedding copies from, and for an attribute inherited from a @MappedSuperclass it went to the superclass own FieldMetaData, so in both cases the last resolved entity won for all of them. Overrides now apply only to the per-embedding copy and to the entity own redefinition of an inherited field, and an override on an @ElementCollection of an embeddable — which was previously ignored — is applied as well. A converter declared on the embeddable own attribute still applies everywhere.

…superclass meta

propagateEmbeddedConverters() set the converter both on the per-embedding
embedded metadata copy and on the repository-level ClassMetaData of the
embeddable type. The latter is shared by every entity embedding that
embeddable, so a @convert(attributeName=...) declared by one entity leaked
into all other embeddings (last resolved wins). Only the per-embedding copy
is updated now. A converter declared on the embeddable's own attribute is
unaffected and still applies everywhere.

A class-level @convert(attributeName=...) for an attribute inherited from a
MappedSuperclass leaked the same way: the override was written to the field
metadata owned by the superclass, which getFields() splices into every
sibling subclass. The override is applied to the subclass' own redefinition
of the inherited field now, after defineSuperclassFields() created it.

For a collection or map of embeddables the embedded metadata hangs off the
element resp. key value, not off the field's value, so such overrides were
collected and then silently dropped. All three value slots are considered
now, with "key." and "value." addressing a map's key resp. value.
@rzo1 rzo1 self-assigned this Oct 5, 2026
@rzo1
rzo1 requested review from cristof and solomax October 5, 2026 18:13
@cristof
cristof merged commit 911485b into master Oct 6, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants