"pete.muir(a)jboss.org" wrote : (which leads to the SFSB's remove method being called unless you explicitly ask it not to). How do you "explicitly ask it not to"? The timing of this work is being driven by a support case where the customer is having issues because of the sessionDestroyed call. If there's a workaround, that would be great. anonymous wrote : I can't immediately see any other cases. Would including HttpSessionActivationListener in the policy be helpful? Allow/disallow the passivation/activation callbacks that surround replication. Norman Richards told me earlier this year that those were causing issues for you guys, although you found a workaround. anonymous wrote : Also, it's worth noting that in JBoss 5 we have the ability to automatically insert classes into a Seam apps classpath, allowing us to plugin alternative behaviour - this might be helpful here (Seam currently doesn't provide for plugability here, but it could if needed). The way I'd been thinking about configuring this is user specifies the classname of the policy they want to use in jboss-web.xml. That would end up in the JBossWebMetaData for the war (WebMetaData in 4.x). If Seam had the ability to manipulate the metadata to specify an appropriate policy impl, that would be nice for users. For AS 5 I was thinking of having the default policy impl be the Seam-appropriate one that disallows the sessionDestroyed callbacks on undeploy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176828#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...