I forgot the codez...

Traditional AOP has aspects, i.e. the classes doing the work, and pointcuts: the places where an aspect squeezes itself into. JEE has some AOP as well, but this is only annotation-bound . So I can define an aspect TimeStuff and an annotation @Timed then all methods or classes need to have an the @Timed annotation added to trigger TimeStuff . This is a bit sad, because it means having to modify code which we might not control, nor want to modify since it's nice and clean. With Spring (or full) AOP, we can define a pointcut which cuts to all the methods/classes which we want (either in configuration, or in the aspect itself with an annotation), and the original code is none the wiser. Lovely! Nothing to see here, nothing to forget here. I want that in JEE. It's not quite so simple, but it's doable. See: https://github.com/softwaremill/softwaremill-common/blob/master/softwaremill-debug/src/main/java/com/softwaremill/common/debug/timing/TimingExtension.java Roughl...

In spring you can use the @Transactional annotation to marcate public methods as transactions. Any exception thrown in such an exception causes a rollback... Any exception? No, spring only does so on runtime exceptions. Checked exceptions are allowed and do not result in a rollback. And even then, you can allow some transactions to rollback, or not, with the proper properties for the transactions. For examle, @Transactional(rollbackFor="MyCheckedException.class") will rollback for a specific checked exception, and similarly, you can use @Transactional(noRollbackFor="MyUncheckedException.class") for unchecked exceptions. Of course, you might want to make it a little simpler on yourself. This article on stackoverflow shows us a different way: we can use our own transaction handler by overriding spring's. Let's have a sample interface which defines whether an exception should perform a rollback: interface ConfigurableRollback shouldRollbackOnE...