I don't think that's where your class cast exception comes from. Looking at your stack trace, it seems to be something internal when setting your session context.
Perhaps there is something in your session context that is causing this? Your stack trace says nothing about the JNDI service or TreeCache...
Well, as it turns out it was a "jar" problem.
I had a servlet that created the cache, started it and inserted the TreeCache object in JNDI. I made sure that this servlet always ran first (in WebLogic). The war file had the jboss-cache related jars in its WEB-INF/lib dir
My ear's also had the jboss-cache related jars in its APP-INF/lib dir.
However the JNDI (in WebLogic) would not allow a TreeCache object inserted by the servlet to be cast to a TreeCache object for the EJB because of the two seperate jars.
I therefore took them out of the war and ear files and put them in the (WebLogic) server's path.
All seems hunky dory now.
Strange JNDI behaviour, but I suspect this is a WebLogic rather than a JNDI issue per se.
Yes, I'd think so - I would not expect JNDI to attempt any casting! :)