The API says you MUST never throw an exception unless you want it to stop the transaction: https://github.com/dima767/inspektr/blob/master/inspektr-common/src/main/java/com/github/inspektr/common/spi/PrincipalResolver.java
Since its an Audit Trail, the assumption is you let us know you couldn't determine the user, rather than us trying to discern that from an empty string, thrown exception, etc. On Thu, Jun 9, 2011 at 11:38 AM, Marvin Addison <[email protected]>wrote: > > Is this the issue that was opened? > > The following looks very close but not exactly what I've seen or > described above. > > https://github.com/dima767/inspektr/issues/8 > > What we've seen here at VT happens in > AuditTrailManagementAspect#handleAuditTrail() when the following > throws: > > currentPrincipal = this.auditPrincipalResolver.resolveFrom(joinPoint, > retVal) > > which causes the following to execute in the catch block: > > currentPrincipal = this.auditPrincipalResolver.resolveFrom(joinPoint, e) > > We have a custom resolver that may also throw there as well, leaving > currentPrincipal uninitialized when executeAutiCode runs in the > finally block. Both this case and the one above are very similar in > that the *Aspects need to guarantee that required variables are > initialized in all cases. > > I suppose the initial assumption was that resolvers are simple and > shouldn't throw, but we use ones that do LDAP queries to map a > meaningless integer onto a principal name for X.509 auth to provide > something meaningful for the audit trail. I think it's reasonable to > guard against that assumption since the audit machinery fails in a > pretty ugly way at present. > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
