Analysis: This occurs because of the issue https://issues.jboss.org/browse/WELD-846 (see related GlassFish issue http://java.net/jira/browse/GLASSFISH-15721) around handling Beans from multiple accessible Bean Deployment Archives in a WAR.
In this deployment scenario, there are two bean archives in WEB-INF/lib that houses enabled Interceptors. In GlassFish this is rightly represented as:
[|ID: CDIBUG2, bdaType= WAR, accessibleBDAs #:19, [WEB-INF/lib/myfaces-extcdi-dist-jsf20-0.9.2,WEB-INF/lib/interceptor,,,,,,,,,,,,,,,,,,], Bean Classes #: 3,[net.wessendorf.enterprise.faces.HelloController, net.wessendorf.enterprise.service.PersonService, net.wessendorf.enterprise.service.PersonServerImpl], ejbs=
|---->ID: WEB-INF/lib/myfaces-extcdi-dist-jsf20-0.9.2, bdaType= UNKNOWN, accessibleBDAs #:2, [WEB-INF/lib/interceptor,CDIBUG2,], Bean Classes #: 369,[...], ejbs=
|---->ID: WEB-INF/lib/interceptor, bdaType= JAR, accessibleBDAs #:2, [WEB-INF/lib/myfaces-extcdi-dist-jsf20-0.9.2,CDIBUG2,], Bean Classes #: 2,[net.wessendorf.enterprise.cdi.Timer, net.wessendorf.enterprise.cdi.LoggingInterceptor], ejbs=
However when Weld is validating this Bean archive during deployment, while the code tries to find out if the enabled intercetors in the BeanManager of WEB-INF/lib/interceptor.jar are in the list of its accessible interceptors, the list of accessible interceptors is incorrect and the validator fails.
Since a right fix for this issue requires a new integration of Weld 1.2.0.Beta when it becomes available, please use the workaround described in
GLASSFISH-15721 at  to work around the issue for GF3.1.
- extract the contents of the two Bean archives WEB-INF/lib/interceptor and WEB-INF/lib/myfaces-extcdi-dist-jsf20-0.9.2 into WEB-INF/classes