Hello Brett, thanks for your answer and my apologies if I did 'repeat' the known issue. I just wanted add my point that the most tricky part of the problem is that the javassist class loading will mostly be performed by a parent class loader of the 'container' rather than then application. In my case as already elaborated I crossed checked my deploy able jar by jar and it was clear that I was loading javaassist -3.18.1-GA. As you point out, the conflict must be 'generated' at a higher level.

That brings us to the unfortunate state that for some of us - (depending on the container) it would either very very difficult or it would create an bunch of other classloading issues, in case we try to either by pass or change the classloading order. At the time being I am still examining my current classloading state on Websphere 8.5.5 to eventually identify the 'version' of javassist that sits on top.

IMHO, this API coupling with javassist on version 4.2.8 sounds more significant to me, like it should have been more of a major version. I am not fully following your mainstream development but would be possible this change to be introduced from 4.2.9 and onwards which is the first official JPA 2.1 version?

Anyway, anyhow thanks for your time and merry Christmas, greetings from Greece.