Don't forget the ACID, man
Even if you could do that, it might not (depending on your application's business rules) be a good idea, because your post-processing step would run in a separate transaction to the one in which the controller called persist() or merge(). In other words, the persist/merge might commit, but your post-processing step might roll back, leaving your system in an inconsistent state.
There are two solutions:
- Old skool:
- write a service layer "save" method that encapsulates both the JPA persist/merge call and the post-processing step,
- push the create and update methods into the controller's Java class, and
- modify those methods to call the new save method instead of calling persist/merge, OR
- New skool:
- write an aspect that runs before/after/around your entity's persist and merge methods to perform the necessary additional processing (which I assume automatically takes part in the same transaction)
"Now is the EJB of our discontent made glorious Spring"