[
http://jira.jboss.com/jira/browse/JBSEAM-279?page=comments#action_12341524 ]
ryan dewell commented on JBSEAM-279:
------------------------------------
The work around for EJBNoObjectException in Seam is to use the JBoss annotation @CacheInfo
and manually configure it to the same timeout as the Seam component. We'll all have
to do this until someone at Seam comes up with a better solution.
For example, here's a session scoped component that successfully works around this
Seam / SFSB problem:
--
@Stateful(name="orderSession")
@Scope(ScopeType.SESSION)
@CacheConfig(idleTimeoutSeconds=1800) // Same value as HttpSession timeout
@Name("orderSession")
@Interceptors(SeamInterceptor.class)
--
To make it easier on yourself, put the 1800 value as a final constant in some utility
class. Same situation for conversation scoped. For application scoped components you can
use an idletimoutSeconds of Integer.MAX_VALUE and probably be relatively safe.
Component lifetimes not guaranteed for SFSB backed components.
--------------------------------------------------------------
Key: JBSEAM-279
URL:
http://jira.jboss.com/jira/browse/JBSEAM-279
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 1.0.1
Reporter: ryan dewell
Seam does not guarantee component lifecycles for SFSB backed components.
The container controls when SFSB's are removed / timed out. When Seam accesses an
SFSB that has been removed by the container, it results in an EJBNoSuchObjectException.
The JBoss specific workaround for Session scoped components is to use the @CacheConfig
annotation, setting the idle timeout to match the HttpSession timeout. Similar changes
would have to be made to any Conversation scoped component that uses a timeout greater
than the default SFSB timeout of 5 minutes (which just happens to be the default timeout
for Seam conversations).
There is no workaround for Application scoped components. Once removed by the container,
EJBNoSuchObjectException's will continue to be thrown as Seam tries to access them.
Seam's context model needs to somehow guarantee that its SFSB instances aren't
removed by the container before Seam is finished with them. And/or, it needs to recover
from EJBNoSuchObjectException's more gracefully, especially with regards to
Application scoped components for which there is no workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira