It's unlikely that's the source of the leak, it's just the class loader keeping handles to the JARs. A leak is not necessarily caused by the biggest memory usage.
To find the leak, you need to take memory snapshots before and after some user actions and compare them (remember to do a GC just before each capture) then interpret the delta. Eclipse MAT is decent, a better profiler in my experience is YourKit. They have an eval version.
First of all....YourKit is a great tool. Thanks for the info....
I found my problem and fix it, but I want to make sure I understand something....
My problem was that I had way too many Beans with Scope Type Session. A User would log in and imediately close the browser and log right back in. This was loading a lot of objects into the heap, which in turn was eating up the RAM. I changed the Scope Type to Page for many Beans. Now when a user logs in, very few objects are loaded and the Page Scoped Beans are only loaded when they are needed.
When does a Session Scoped bean get garbage collected versus when a Page Scoped Bean?
I have session timeout set at 10 minuetes in my web.xml but that doesn't seem to have any effect.
From the information Yourkit was giving me, a Session scoped Bean stays in memory well after the user has hit logged out or closed the browser. And stays in memory until is garbaged collected.....
Is this correct?
GC doesn't happen automatically when an object is no longer referenced (and this is not specific to beans or Seam, for that matter). If, when and what kind of GC happens depends on many variables (JVM, JVM settings, usage patterns, environment such as available memory and so on). GC in itself is a complex topic (have a look here to get an idea, there are other papers as well). This has little impact on how you write your application, but might be an interesting read.