[weld-dev] [cdi-tck] cdi tck: org.jboss.cdi.tck.tests.context.application.event.ApplicationScopeEventMultiWarTest

[Emily Jiang]

Thank you Tom and Jozef!

On Mon, May 25, 2015 at 9:39 AM, Tomas Remes <tremes at redhat.com> wrote:

>
> Hi Emily,
>
> Yes I am already working on that. As I commented on the isssue.
>
> Thank's
> Tom
>
> ----- Original Message -----
> From: "Emily Jiang" <emijiang6 at googlemail.com>
> To: "Jozef Hartinger" <jharting at redhat.com>
> Cc: "cdi-tck" <cdi-tck at lists.jboss.org>, "Weld-Dev List" <
> weld-dev at lists.jboss.org>
> Sent: Monday, May 25, 2015 10:31:31 AM
> Subject: Re: [cdi-tck] [weld-dev] cdi tck:
> org.jboss.cdi.tck.tests.context.application.event.ApplicationScopeEventMultiWarTest
>
> Thank you Jozef! By the way, the tck-484 was logged a few days ago but its
> description was not clear enough, so Tomas Remes had some question on it.
> With my detailed explaination, can you guys work together to get this issue
> solved? Thank you very much!
>
> On Mon, May 25, 2015 at 7:03 AM, Jozef Hartinger < jharting at redhat.com >
> wrote:
>
>
>
> Hi Emily,
>
> I cannot find anything in the CDI spec that would prevent lazy
> initialization of the web container. Therefore, I think you are right and
> the test should be modified. There is already a CDI TCK ticket at
> https://issues.jboss.org/browse/CDITCK-484
>
> Jozef
>
>
> On 05/24/2015 04:21 PM, Emily Jiang wrote:
>
>
>
> I am trying to run the cdi tck:
> org.jboss.cdi.tck.tests.context.application.event.ApplicationScopeEventMultiWarTest
> Method: testDeployment
>
> It seems this test is to verify whether both web modules receive the
> initilization event of ApplicationScoped. The confusing bit is that the
> test directly verfies whether both events are received without trying to
> send request to activate the web modules. I think the test assume web
> modules are active and did not consider the fact of that some application
> server starts the modules in a lazy mode.
>
> The CDI spec says:
> The application scope is active:
> • during the service() method of any servlet in the web application,
> during the doFilter()
> method of any servlet filter and when the container calls any
> ServletContextListener,
> HttpSessionListener, AsyncListener or ServletRequestListener
>
> According to cdi spec 6.7.3:
> An event with qualifier @Initialized(ApplicationScoped.class) is fired
> when the application
> context is initialized and an event with qualifier
> @Destroyed(ApplicationScoped.class) is fired
> when the application is destroyed. The event payload is:
> • the ServletContext if the application is a web application deployed to a
> Servlet container, or
> • any java.lang.Object for other types of application.
> The spec did not say whether the event should be recieved. In my
> environment, if the web module url is hit, the obeserved event will be
> obsevered.
>
> I think we have implemented this correctly as I can confirm the
> application scope is active when a request is sent and the event of
> @Initialized(ApplicationScoped.class) is received as well but the test
> assumes the web module is active automatically without even needing to send
> the first request.
>
> Can someone shed some lights on this? What is the test trying to do? I am
> suggesting the test should be updated to send the first request first
> before checking the size of the obsevers.
>
> I did not directly send to cdi tck as I would like to get some input from
> weld dev list first.
>
> --
> 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
>
> _______________________________________________
>
>
>


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