[deanhiller2000]

or if you are in jdk 1.6, enable the new awesome property of

-Dsun.io.serialization.extendedDebugInfo=true

sweeeeeeet.  It logs the object heirarchy of serialization to your failure(damn sweet)...

2010-09-23 22:50:22,473 ERROR [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (http-0.0.0.0-8080-3) N/A  java.io.NotSerializableException: net.voicelog.entities.scripts.ScriptModelVersion
     - field (class "net.voicelog.entities.Subaccount", name: "liveScript", type: "class net.voicelog.entities.scripts.ScriptModelVersion")
     - object (class "net.voicelog.entities.Subaccount", [sub:50044] )
     - field (class "net.voicelog.entities.Reasoncodes", name: "subaccount", type: "class net.voicelog.entities.Subaccount")
     - object (class "net.voicelog.entities.Reasoncodes", 90-Voicemail was reached on Callback)
     - field (class "net.voicelog.entities.Tpvtrans", name: "reasoncdobjid", type: "class net.voicelog.entities.Reasoncodes")
     - object (class "net.voicelog.entities.Tpvtrans", [tpvid:1520100913000000:ctiid:2010065219] )
     - field (class "org.jboss.seam.contexts.EntityBean", name: "instance", type: "class java.lang.Object")
     - object (class "org.jboss.seam.contexts.EntityBean", org.jboss.seam.contexts.EntityBean@8c9de8)
     - custom writeObject data (class "java.util.HashMap")
     - root object (class "java.util.HashMap", {vRememberMe=net.voicelog.seam.overrides.RememberMe@1bd700a, org.jboss.seam.security.rememberMe=org.jboss.seam.security.RememberMe@6b6f5, org.ajax4jsf.application.AjaxStateHolder=org.ajax4jsf.application.AjaxStateHolder@9c5571, org.jboss.seam.CONVERSATION#10$loadScript=[i:0], org.jboss.seam.CONVERSATION#10$ansQuestion=[q:1,Welcome:id:13444] , org.jboss.seam.international.localeSelector=org.jboss.seam.international.LocaleSelector@d5a046, org.jboss.seam.core.conversationEntries=ConversationEntries([ConversationEntry(10)]), org.jboss.seam.CONVERSATION#10$loadScript.comments=org.jboss.seam.contexts.E

so the HashMap is the session I think seam is serializing the whole thing??  that seems quite odd?  I really don't want that Tpvtrans clustered/serialized...so I am goin to get rid of it's implements serializable and hope seam skips it. 

Why is seam not seam/jboss not serializing each item separately in the session?

[deanhiller2000]

gah!

so I am reading into tomcat and any time setAttribute is called, it will cluster which means EVERY entity bean I put in session will be clustered even if I don't want it too......BUT I think seam should be putting proxies that would just load stuff from the database instead of putting my bean in the session.  BUT it seems like seam is not doing that form this outjection stack trace....

Caused by: java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute
        at org.jboss.web.tomcat.service.session.ClusteredSession.setAttribute(ClusteredSession.java:856)
        at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:130)
        at com.sun.faces.context.SessionMap.put(ExternalContextImpl.java:971)
        at org.jboss.seam.contexts.BasicContext.set(BasicContext.java:84)
        at org.jboss.seam.Component.outjectAttribute(Component.java:1806)
        at org.jboss.seam.Component.outjectAttributes(Component.java:1755)
        at org.jboss.seam.Component.outject(Component.java:1608)
        at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:86)

and of course, there is no info on what class went wrong :( in any of the exceptions in the chain.  jboss doesn't put that info in and seam doesn't catch and rethrow with that info :(....grrr.

This seems like a major flaw when I am putting lots of Entity beans in a session that I do NOT want clustered...I don't care if their proxies are clustered as hopefully that would simply be a primary key(very small). 
OR
does seam have a way where I tell it I don't want these clustered but just
want them readonly and it would just cluster the proxy.

NOTE: Almost all my methods relookup entity beans and the ids are clustered instead. 

The problem gets worse too ;(.  if that entity happens to have done an eager fetch on other stuff, they are being clustered as well :(.