<div dir="ltr">ah. ok. It makes sense. We will update our test framework. Thanks all!<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 8, 2015 at 12:21 PM, Pete Muir <span dir="ltr"><<a href="mailto:pmuir@redhat.com" target="_blank">pmuir@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mark is correct.<br>
<br>
The TCK needs to be able to get hold of the Context implementation when the Context is not active, in order to verify that "If the context object is inactive, the get() and destroy() methods must throw a ContextNotActiveException.” (section 6.2). As you can’t get a context impl from BeanManager when the context is not active, it needs to use the porting package API instead.<br>
<span class=""><br>
> 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<br>
<br>
</span>Yes, however it is not a direct call, and this call is replaceable as described in the TCK docs <a href="http://docs.jboss.org/cdi/tck/reference/1.2.4.Final/en-US/html_single/#porting-package" target="_blank">http://docs.jboss.org/cdi/tck/reference/1.2.4.Final/en-US/html_single/#porting-package</a>. You can replace the call to Container with whatever works for you (e.g. a JNDI lookup).<br>
<span class=""><br>
> >> 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).<br>
<br>
<br>
</span>You need to implement a version of the porting package that calls your implementation / container with the correct arguments. The porting package provided with Weld is provided for reference only.<br>
<div class="HOEnZb"><div class="h5"><br>
> On 8 May 2015, at 09:00, Emily Jiang <<a href="mailto:emijiang6@googlemail.com">emijiang6@googlemail.com</a>> wrote:<br>
><br>
> Mark,<br>
> 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.<br>
> Thanks<br>
> Emily<br>
><br>
> On Thu, May 7, 2015 at 6:29 PM, Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>> wrote:<br>
> No it makes perfect sense in _some_ cases to use Contexts.getRequestContxt() as BeanManager.getContext(RequestScoped.class) might throw a ContextNotActiveException.<br>
><br>
> LieGrue,<br>
> strub<br>
><br>
><br>
><br>
> > Am 07.05.2015 um 17:02 schrieb Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>>:<br>
> ><br>
> > Hi Emily,<br>
> ><br>
> > you can submit TCK challenges direcly by opening JIRA issues at <a href="https://issues.jboss.org/browse/CDITCK" target="_blank">https://issues.jboss.org/browse/CDITCK</a>.<br>
> ><br>
> > 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.<br>
> ><br>
> > Jozef<br>
> ><br>
> > On 05/07/2015 01:50 PM, Emily Jiang wrote:<br>
> >><br>
> >> I am trying to run cdi 1.2 tck:<br>
> >> In test: org.jboss.cdi.tck.tests.event.observer.conditional.ConditionalObserverTest<br>
> >> Method: testConditionalObserverMethodNotInvokedIfNoActiveContext<br>
> >><br>
> >> I got this following failure:<br>
> >> 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]<br>
> >> at org.jboss.weld.bootstrap.api.helpers.RegistrySingletonProvider$RegistrySingleton.get(RegistrySingletonProvider.java:28)<br>
> >> at org.jboss.weld.Container.instance(Container.java:55)<br>
> >> at org.jboss.weld.tck.ContextsImpl.getRequestContext(ContextsImpl.java:33)<br>
> >> at org.jboss.weld.tck.ContextsImpl.getRequestContext(ContextsImpl.java:30)<br>
> >> at org.jboss.cdi.tck.tests.event.observer.conditional.ConditionalObserverTest.testConditionalObserverMethodNotInvokedIfNoActiveContext(ConditionalObserverTest.java:96)<br>
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<br>
> >><br>
> >> From the stack trace, two strange things are happening:<br>
> >><br>
> >> 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<br>
> >> 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).<br>
> >><br>
> >> Can someone help to explain why the tck test was done this way? Is it accurate?<br>
> >><br>
> >> --<br>
> >> Thanks<br>
> >> Emily<br>
> >> =================<br>
> >> Emily Jiang<br>
> >> <a href="mailto:ejiang@apache.org">ejiang@apache.org</a><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> weld-dev mailing list<br>
> >><br>
> >> <a href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>
> ><br>
> > _______________________________________________<br>
> > weld-dev mailing list<br>
> > <a href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Thanks<br>
> Emily<br>
> =================<br>
> Emily Jiang<br>
> <a href="mailto:ejiang@apache.org">ejiang@apache.org</a><br>
> _______________________________________________<br>
> weld-dev mailing list<br>
> <a href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Thanks<br>Emily<br>=================<br>Emily Jiang<br><a href="mailto:ejiang@apache.org" target="_blank">ejiang@apache.org</a><br></div>
</div>