[weld-dev] CDI 1.2 tck challenge 1

[Emily Jiang]

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 <struberg at yahoo.de> 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 <jharting at redhat.com>:
> >
> > 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
> >> ejiang at apache.org
> >>
> >>
> >> _______________________________________________
> >> weld-dev mailing list
> >>
> >> weld-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/weld-dev
> >
> > _______________________________________________
> > weld-dev mailing list
> > weld-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/weld-dev
>
>


-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150508/1ef844a8/attachment.html