CDI TCK 1.1.6.Final
by Tomas Remes
Hi,
The CDI TCK 1.1.6.Final was released. This is hopefully last release in 1.1.x branch.
Thank's
--
Tomas Remes
9 years, 6 months
Re: [cdi-tck] [weld-dev] cdi tck: org.jboss.cdi.tck.tests.context.application.event.ApplicationScopeEventMultiWarTest
by Jozef Hartinger
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(a)apache.org <mailto:ejiang@apache.org>
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
9 years, 7 months
CDI TCK 2.0.0.Alpha2
by Tomas Remes
Hi,
Version 2.0.0.Alpha2 was released. Note that this still uses/depends on CDI API 1.2. This is mainly maintenance bug-fixing release which also includes some version updates (Arquillian, TestNG).
Bye
--
Tomas Remes
9 years, 7 months
Re: [cdi-tck] [weld-dev] Validation on Alternative/Interceptor/Decorator mentioned in beans.xml
by Jozef Hartinger
Hi Emily,
I see what you are saying. I agree that the test would be better if
tested a more realistic scenario where a bean archive contains some
classes. Unless there are objections e.g. from the TCK lead I do not see
a problem improving the test this way.
Jozef
On 05/07/2015 01:57 PM, Emily Jiang wrote:
> Thank you Jozef or your reply. have brought this discussion in the cdi
> dev as I think the spec is contradicting itself. Anyway, this question
> is related to one tck test
> org.jboss.cdi.tck.tests.alternative.broken.incorrect.name.NoClassWithSpecifiedNameTest
> org.jboss.cdi.tck.tests.alternative.broken.incorrect.name.stereotype.NoAnnotationWithSpecifiedNameTest
>
> This tck is to test a scenario where no classes in the web-inf\classes
> but one beans.xml. In this beans.xml, an invalid class was specified
> in the alternative list. The test is expecting a deployment. In my
> interpretation, I won't create any archive for it as there is no
> classes. What is the value to create one with beans.xml but nothing
> else (by the way, no other accessible bean archives either). What is
> the value of this test? I think the test should be modified to include
> a class. Thoughts?
>
> On Mon, May 4, 2015 at 7:30 AM, Jozef Hartinger <jharting(a)redhat.com
> <mailto:jharting@redhat.com>> wrote:
>
> Hi Emily,
>
> jar1 and jar2 would be bean archives on their own. If such archive
> declares beans.xml then that one is used. Otherwise, the bean
> archive may be implicit (no beans.xml but bean-defining
> annotation). Either way, no other beans.xml file is used instead
> for that particular jar.
>
> HTH,
>
> Jozef
>
>
> On 04/30/2015 11:34 PM, Emily Jiang wrote:
>> Thanks Jozef! I figured out why I did not get an error:
>>
>> my war:
>> web-inf\beans.xml (containing invalid class as alternatives)
>> web-inf\lib\jar1.jar
>> web-inf\lib\jar2.jar
>> [no web-inf\classes]
>> In either jar1.jar or jar2.jar, there is no beans.xml and no
>> bean-defining annotations. Do you think the jar1.jar and jar2.jar
>> should use the beans.xml in the web-inf? If yes, what if there is
>> beans.xml packaged in either jar1.jar or jar2.jar? I cannot find
>> any clear instruction on this scenario.
>> Thanks,
>> Emily
>>
>> On Thu, Apr 30, 2015 at 6:24 AM, Jozef Hartinger
>> <jharting(a)redhat.com <mailto:jharting@redhat.com>> wrote:
>>
>> Hi Emily,
>>
>> Weld performs all these validations.
>>
>> Jozef
>>
>>
>> On 04/29/2015 11:52 PM, Emily Jiang wrote:
>>> CDI1.2 spec section 8.2.2 says:
>>> In the beans.xml
>>> Each child <class> element must specify the name of a
>>> decorator bean class. If there is no class with the
>>> specified name, or if the class with the specified name is
>>> not a decorator bean class, the container automatically
>>> detects the problem and treats it as a deployment problem.
>>> If the same class is listed twice under the <decorators>
>>> element, the container automatically detects the problem and
>>> treats it as a deployment problem.
>>>
>>> Will Weld do the validation or Weld expects the integrator
>>> to do the validation?
>>>
>>> I am confused about what validations are done by the spec
>>> reference implemenatation (RI) or RI consumer.
>>> --
>>> Thanks
>>> Emily
>>> =================
>>> Emily Jiang
>>> ejiang(a)apache.org <mailto:ejiang@apache.org>
>>>
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>>
>>
>>
>> --
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang(a)apache.org <mailto:ejiang@apache.org>
>
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang(a)apache.org <mailto:ejiang@apache.org>
9 years, 7 months
Re: [cdi-tck] [weld-dev] CDI 1.2 tck challenge 1
by Jozef Hartinger
Right, I missed that use-case.
On 05/07/2015 07:29 PM, Mark Struberg 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(a)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(a)apache.org
>>>
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>>
>>> weld-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
9 years, 7 months
Re: [cdi-tck] [weld-dev] CDI 1.2 tck challenge 1
by Jozef Hartinger
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(a)apache.org <mailto:ejiang@apache.org>
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
9 years, 7 months
