Instead we are getting a Spring UnexpectedRollbackException wrapping a Weblogic AppSetRollbackOnlyException with the original cause no where to be found.

Hmm, that is odd behaviour as it looks like the attempt to mark the active tx as rollback only failed. What does it mean if calling Transaction.setRollbackOnly() throws an exception? What will the transaction manager do when it catches the exception thrown from Synchronization.beforeCompletion?

The above suggestions sound good but they don't cover the more important case (IMO), that the call to setRollbackOnly() actually failed for a reason that should be reflected in the thrown exception.

I'm not sure of the best improvement but am wondering if the caught exception should be logged before calling setRollbackOnly() in case that fails.