@danielwegener Why "final" is preferred in this case? I noticed TraceeQueueSender and TraceeTopicPublisher are final too. Security concern?

I ment the instance variable delegation, not the class itself.

Maybe others would disagree but I strongly think that final is a much more sensible default for instance variables. It reduces the possible states of the program execution. In this case it means: Whenever you have a TraceeWrappedConnection, you can be sure that it will always delegate to the same Connection instance (just by looking at the constructor and the field, you do not need to read & understand other methods and see if they' somehow mutate the delegation field). This improves local reasoning alot.
So to answer your question - for me - for instance variables final is always preferred except you have a good reason for a mutable instance variable.

You mentioned other classes like TraceeQueueSender. These are final mostly because it seals their hierarchy and tells you: Whenever you have a TraceeQueueSender, it will always behave the same because it can not be inherited with a changed behaviour. However, this does not play well with testability (you can not create Mocks/Spies for final classes) and creates problems with some runtime frameworks (like spring or ejb, cdi, see #134) who need to create runtime proxies for these classes. So we are fine to leave classes and methods non-final.

@danielwegener Got it. Totally agree with final member. What do you think of the spring-jms extension? If you think the design fits Tracee, I'll prepare the completed pull request later.

@Hippoom

In fact, thats why we wanted to release tracee as community project - so people can contribute extensions to the frameworks they need and that could be useful for others. We'd think twice about very special/esoteric bindings but spring-jms looks well established enough (tbh I didn't even know it exists :)).
The design looks alright - well - tests and docs are missing. I guess TraceeWrappedConnection and TraceeWrappedSession could also become a new possible way for plain JMS users to integrate tracee? If so, we should also change them to the JMS documentation. If not, I'd push them down to the spring-jms-binding module.

Otherwise looks like a good attempt so far. Always keen to hear @SvenBunge optinion on those changes, but he is kind of busy lately.

I would like to dive into. Pls give me some time to check it. Private responsibilities until the end of February. Maybe I'll find some time to get into Spring-JMS earlier. Sorry @Hippoom .

I've created Milestone 1.2.0 to release the new feature.

@SvenBunge That's OK.

Hey @Hippoom ,
I've tried an own PoC with #145 . I think it's not necessary to wrap the whole Spring API. I would like to hear your opinion about my PoC in #145.

@danielwegener Please review this approach and adopt it for tracee 2.x