[weld-dev] CDI 1.2 tck challenge 1

[Emily Jiang]

ah. ok. It makes sense. We will update our test framework. Thanks all!

On Fri, May 8, 2015 at 12:21 PM, Pete Muir <pmuir at redhat.com> wrote:

> Mark is correct.
>
> 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.
>
> > 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
>
> Yes, however it is not a direct call, and this call is replaceable as
> described in the TCK docs
> http://docs.jboss.org/cdi/tck/reference/1.2.4.Final/en-US/html_single/#porting-package.
> You can replace the call to Container with whatever works for you (e.g. a
> JNDI lookup).
>
> > >> 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).
>
>
> 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.
>
> > On 8 May 2015, at 09:00, Emily Jiang <emijiang6 at googlemail.com> wrote:
> >
> > 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
> > _______________________________________________
> > 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/20150509/c9ceaa2c/attachment-0001.html