Could you look at what has (strong) references to the Moduleclassloader instances that are holding the entity classes. We previously fixed some issues where there were Thread instances (via thread local) referencing deployment classes after undeployment. Those were fixed but I mention them, just to give you an idea of what could be keeping what sounds like the application deployment Moduleclassloader in memory.
When you look at the heap dump in eclipse memory analyzer, you need to look at the incoming references to the entity classes. Which, I think you did, as you saw that its the moduleclassloader instance. You need to repeat and see what is keeping the moduleclassloader in memory. There is also another view in eclipse memory analyzer, to show gc references to their roots that might also be helpful.
Ok guys thanks for the ideas,
I can continue my work for this issue tomorrow. I'll report about the progress.
I have litte more time from the daily development stuff and reopened my PermGenSpace problem again.
For to know if the leak is on our side or on jboss site I create a simple war project with my project dependencies. I see the problem still exisits.
So far so good.
I delete dependency by depency and show the PermGenSpace after every hotdeployment. After delete the dependency to Primefaces 3.5 the problem is going.
I haven't the problem with Primefaces 4.0-SNAPSHOT. It seems so that PF was the culprit.