Mark, Are you saying you might get a request scope Context via contexts.getRequestionContext() even if the context is not active while the BeanManager.getContext(RequestScoped.class) gives you a better exception instead? The javadoc on BeanManger states that you should get a ContextActiveException if the context is not active. Anyway, I think BeanManager.getContext(RequestScoped.class) is widely used and it is an api. Thanks Emily
On Thu, May 7, 2015 at 6:29 PM, Mark Struberg <[email protected]> wrote: > No it makes perfect sense in _some_ cases to use > Contexts.getRequestContxt() as BeanManager.getContext(RequestScoped.class) > might throw a ContextNotActiveException. > > LieGrue, > strub > > > > > Am 07.05.2015 um 17:02 schrieb Jozef Hartinger <[email protected]>: > > > > Hi Emily, > > > > you can submit TCK challenges direcly by opening JIRA issues at > https://issues.jboss.org/browse/CDITCK. > > > > As for this particular one I am not sure why the > Contexts.getRequestContext() method is still used in the tests. > BeanManager.getContext(RequestScoped.class) should IMHO be used instead. > > > > Jozef > > > > On 05/07/2015 01:50 PM, Emily Jiang wrote: > >> > >> I am trying to run cdi 1.2 tck: > >> In test: > org.jboss.cdi.tck.tests.event.observer.conditional.ConditionalObserverTest > >> Method: testConditionalObserverMethodNotInvokedIfNoActiveContext > >> > >> I got this following failure: > >> java.lang.IllegalStateException: Singleton not set for STATIC_INSTANCE > => [29478a84-0d13-49f5-b140-34a6cd92ab71, > 0dd30cdc-10f4-4ec0-a8c5-d8fa3a82fc25, bbc59ac1-4747-49d0-96a3-12f0d4987829, > 3459400f-dd41-473c-a4db-94d60fe5899b, 10795c17-3611-41d5-b7ca-497709c2ad53, > f10c929f-5314-44ba-aeb4-99888f6b4611, a22c5a8f-bf26-4f54-a847-d1c7b5532426, > 00c3de8d-65d9-4ba7-804a-9c3c515e59d7, d7c8be7e-8b52-4c88-97e1-5ba6925fb794, > 72ac8455-7c21-4090-b7ec-13d70c75a7d7, dbe7255d-5485-4c2a-b547-058815660144, > d3bb3d00-3214-48a5-b662-499010197e12] > >> at > org.jboss.weld.bootstrap.api.helpers.RegistrySingletonProvider$RegistrySingleton.get(RegistrySingletonProvider.java:28) > >> at org.jboss.weld.Container.instance(Container.java:55) > >> at > org.jboss.weld.tck.ContextsImpl.getRequestContext(ContextsImpl.java:33) > >> at > org.jboss.weld.tck.ContextsImpl.getRequestContext(ContextsImpl.java:30) > >> at > org.jboss.cdi.tck.tests.event.observer.conditional.ConditionalObserverTest.testConditionalObserverMethodNotInvokedIfNoActiveContext(ConditionalObserverTest.java:96) > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> > >> From the stack trace, two strange things are happening: > >> > >> 1) the TCK code is calling into org.jboss.weld.Container which is an > internal Weld class which should not be visible to application so the > application should not need to load them > >> 2) the TCK code is calling Container.instance() with no arguments, > which should not be called. We always use Container.instance(contextId), in > accordance with Weld doc A.3.2.4. Singleton SPI (this should be used in > OSGi environment). > >> > >> Can someone help to explain why the tck test was done this way? Is it > accurate? > >> > >> -- > >> Thanks > >> Emily > >> ================= > >> Emily Jiang > >> [email protected] > >> > >> > >> _______________________________________________ > >> weld-dev mailing list > >> > >> [email protected] > >> https://lists.jboss.org/mailman/listinfo/weld-dev > > > > _______________________________________________ > > weld-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/weld-dev > > -- Thanks Emily ================= Emily Jiang [email protected]
_______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
