Yes I see that thread. Using the XML descriptor is merely configuring that annotation, so they are functionally equivalent. The XML has the downside of not being granular enough to say that Session scoped SFSB should have a longer timeout than say a Conversation scoped SFSB.
You're up against Seam and JBoss notions of SFSB lifetimes, and AFAIK @CacheConfig is the ONLY way to handle this granularly. I'm originally reported this SFSB timeout issue with Seam: http://jira.jboss.org/jira/browse/JBSEAM-279 As is reported in that ticket, @CacheConfig used to solve this lifetime mismatch. I don't like the solution either, but there really was/is no other solution. As of sometime between b1 and cr1, however, something has happened and @CacheConfig doesn't do the trick anymore. Actually, it's even worse than before that reported ticket. On a related note, I'd really like to know how Seam is going to handle this problem across different JEE implementations. Could Seam "ping" the SFSB's it controls periodically so the container doesn't time them out? OR, are you suggesting that in the XML configuration we should set the SFSB timeout to Integer.MAX_VALUE? Effectively telling JBoss to never expire SFSB beans? That just seems like it would very dangerous and put a lot of responsibility on Seam to cleanup unexpected problems with lingering SFSB's. OR, if from Seam's standpoint this is a benign warning, could it do something else besides throw up a stack trace? Like: "WARN: Seam could not destroy component XVB. This is probably safe to ignore, but may represent an SFSB timeout setting that is too low for the Seam scope." View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990176#3990176 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990176 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
