> So the basic rule is:
> - fields from a non-audited mapped superclass are never audited, unless an
> @AuditOverride is specified
> - if the mapped superclass is audited, then its fields are of course audited
> as well
> > In the following, A.b.intValue should be audited; A.b.strValue should not
> > be audited.
> Looks good
> > In the following, both A.b.intValue and A.b.strValue should be audited:
> > In the following, both A.b.intValue and A.b.strValue should be audited.
> > What should be the outcome of the following? Should A.b.strValue still be
> > audited even though A.b is explicitly not audited?
> @NotAudited has precedence - so not audited.
> Adam Warski
Currently, what is listed in the description only works if the embeddable class has (persistent) declared values.
As a workaround, when an embeddable class with no declared data extends a mapped superclass, auditing can only be enabled for the mapped superclass data by annotating the embeddable class with @Audited. For example,
Unfortunately, this will affect all audited entities that contain an embedded instance of that class. Currently, @AuditOverride cannot be used on an embedded field to disable auditing the mapped superclass (HHH-9228). The only way to override auditing for a particular embedded field is to annotate the embedded field with @NotAudited.
In addition, @AuditOverride( ... isAudited=false) does not for embeddables that extend a mapped-superclass.
This bug report does not indicate that the reported issue affects version 5.x. Versions prior to 5.x are no longer maintained. It would be a great help to the Hibernate team and community for someone to verify that the reported issue still affects version 5.x. If so, please add the 5.x version that you verified with to the list of affected-versions and attach the (preferably SSCCE) test case you used to do the verification to the report; from there the issues will be looked at during our triage meetings.
For details, see http://in.relation.to/2015/10/27/great-jira-cleanup-2015/
As part of verifying that this issue affects 5.0, please just set the "Affects version". Leave the "verify-affects-5.0" label and leave the issue in "Awaiting Response" status; these are critical for us to be able to track these verifications and triage them. Thanks.
Preparing Alpha1 release