> 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
