For context package test:

org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest

There are 2 assertions on glassfish v3:

org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest.testRequestScopeActiveDuringCallToEjbTimeoutMethod(EJBRequestContextTest.java:36)
org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest.testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(EJBRequestContextTest.java:53)

I think Weld is not doing the right thing here. See the analysis below:

In FMSModeIII, the timer expire time is 200 ms. The test waits for 250 ms so that timeout() is invoked and sets requestScopeActive to true.

In the EJBRequestcontextCode:

flightManagementSystem.climb(); ==> a timer is created with 200 ms duration
Thread.sleep(250); ==> sleep for 250 ms and timeout is called
assert flightManagementSystem.isRequestScopeActive(); ==> Due to the exception below, the flag requestScopeActive, which was supposed to be set in timeout() method was never set.

Caused by: javax.enterprise.context.ContextNotActiveException: No active contexts for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.BeanManagerImpl.getContext(BeanManagerImpl.java:928)
at org.jboss.jsr299.tck.tests.context.request.ejb.FMSModelIII.timeout(FMSModelIII.java:50)

Under jsr 299 spec 6.7.1:

--------
The request context is provided by a built-in context object for the built-in scope type @RequestScoped. The request scope is active:

• during any remote method invocation of any EJB, during any asynchronous method invocation of any EJB, during any call to an EJB timeout method and during message delivery to any EJB message-driven bean, and
  ----------

However during timeout() method call beanManager.getContext(RequestScoped.class).isActive() returns false. Which seems to violate the above requirement in 6.7.1.