May 2015 - weld-dev - Jboss List Archives

by Jozef Hartinger

I've created a new branch named *2.3* in the weld repo. This branch is going to host the 2.3.x stream of Weld releases. Weld 2.3 will remain a CDI 1.2 implementation. We are incrementing the minor version due to several new features we plan on adding. A final release of Weld 2.3 is planned to be released this summer. Our CI setup has been updated to test this new branch regularly. Note that from now on, we are dropping Java 6 support and therefore Java 7 is the minimal requirement for building and running Weld 2.3 Jozef

10 years, 11 months

1
0
0 / 0

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

by Emily Jiang

Thank you Tom and Jozef! On Mon, May 25, 2015 at 9:39 AM, Tomas Remes <tremes(a)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(a)googlemail.com> > To: "Jozef Hartinger" <jharting(a)redhat.com> > Cc: "cdi-tck" <cdi-tck(a)lists.jboss.org>, "Weld-Dev List" < > weld-dev(a)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(a)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(a)apache.org > > > _______________________________________________ > weld-dev mailing list weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang(a)apache.org > > _______________________________________________ > > > -- Thanks Emily ================= Emily Jiang ejiang(a)apache.org

10 years, 11 months

1
0
0 / 0

cdi tck: org.jboss.cdi.tck.tests.context.application.event.ApplicationScopeEventMultiWarTest

by Emily Jiang

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

10 years, 11 months

2
2
0 / 0

Weld releases

by Jozef Hartinger

Weld 3.0.0.Alpha9 and 2.2.12.Final have been released. http://weld.cdi-spec.org/download/

10 years, 11 months

1
0
0 / 0

Weld 2.2.x runs against CDI 1.1 cts vs. CDI 1.2 cts?

by Emily Jiang

In the past, I talked to Jozef/Martin regarding whether Weld 2.2.x runs against CDI 1.1 cts or CDI 1.2 cts. If I can remember correctly, I was told Weld 2.2.x runs against CDI 1.2 cts only. Can someone confirm whether you expect Weld 2.2.x passes CDI 1.1 cts as well or you have stopped maintaining CDI 1.1 cts and only runs against CDI 1.2 cts? We found the same test does different things between CDI 1.1 cts and CDI 1.2 cts. -- Thanks Emily ================= Emily Jiang ejiang(a)apache.org

10 years, 11 months

2
2
0 / 0

Interceptors

by Emily Jiang

I have a few questions on interceptors: 1. CDI Interceptors on cdi beans Will the interceptors share the same creational context as the bean it is associated with? Will Weld managed the cdi interceptors as well as the old-styled interceptors? @Interceptors don't work on other cdi beans except ejb and managed beans, right? 2. Interceptors on ejb beans or managed beans I think the integrator needs to create these @Interceptors and cdi interceptors. Will these interceptors use the non-contextual creational context (scope @Dependent) or use the ejb or managed bean's creational context? Will Weld destroy the interceptors when the associated beans are destroyed or the integrator need to destroy them? This logic applicable to both cdi interceptors and @Interceptors style interceptors, right? 3. Interceptors on JavaEE components I think this interceptors are created by Weld when the JavaEE component classes are created, right? By the way, how can the container make sure to destroy the interceptors? -- Thanks Emily ================= Emily Jiang ejiang(a)apache.org

10 years, 12 months

3
5
0 / 0

Injection Services cannot handler producer on a static field

by Emily Jiang

I am trying to run cdi cts and failed on the following test: org.jboss.cdi.tck.tests.implementation.simple.resource.ws.staticProducer.WebServiceResourceStaticProducerFieldTest.testResourceProduced(WebServiceResourceStaticProducerFieldTest.java:46) The test is to test the following produer: @Produces @WebServiceRef private static MyClass wsRef; On further investigation,it seems like Weld has a special call that it makes when a producer field is static but also annotated with a JavaEE resource. Eventually that calls to JaxwsInjectionServices, a weld SPI that we don't implement and falls back to just getting the value of the static field, which may not be set. We followed the Weld integration guide which said that we can handle JavaEE resource injection either by implementing the SPI InjectionServices where we can hook every injection call and to additional injection ourselves, or by implementing EjbInjectionServices, JaxwsInjectionServices, JpaInjectionServices and ResourceInjectionServices, all of which return a factory which produces the instance that weld will then inject. We implemented the former because it lets us just call our injectionengine, but Weld doesn't seem to use this SPI at all when handling static producer fields. Can someone confirm or give me some pointers how to fix this problem? -- Thanks Emily ================= Emily Jiang ejiang(a)apache.org

11 years

2
1
0 / 0

ECCN for weld

by Beurer, Maria (Coriant - DE/Munich)

Hello, We use weld in our commercial product and therefore need to know the ECCN for it. The ECCN is an international Export control and compliance number that is necessary for EVERY Export. Most of the european countries specify their goods according to the european commerce control list (EG dual-use list : http://ec.europa.eu/trade/index_en.htm). So for export of a commercial Software using weld ( or any other open source or OEM Software), we need to document the libs, on one side to comply with license obligations and on the other side the ECCNs for Export restrictions. Please note, as the US regulations also care about re-export of US items ( any stuff that contains US Content above a certain Limit), we need to specify both; the EU-ECCN and the US-ECCN and hopefully the US license exception that applies (e.g. TSU for open source). So please specify the ECCN for weld or answer the following questions: - Country of origin ( where is weld Software mainly developed) - is there US Content in there? ( e.g. other open source libs) - Is the SW designed or modified to use cryptography performing any cryptographic function other than authentication or digital signature? (y/n) -if yes, -- key length symetric -- Bit length asymmetric Thanks and kind regards Maria Beurer Mit freundlichen Grüßen / Kind Regards / Com os melhores cumprimentos! Maria Beurer [cid:image001.png@01D01091.4F1BD1F0] Coriant GmbH Maria Beurer R&D Engineer Coriant R&D GmbH SW OSS&Transnet TNTC DE St.-Martin-Str. 76 81541 München Tel: +49 89 5402 15138 maria.beurer(a)coriant.com<mailto:maria.beurer@coriant.com> http://www.coriant.com [cid:image004.png@01D08645.87B02DC0]Think before you print Coriant GmbH registered under / registriert unter: HRB 202750 | WEEE-Reg.-No. DE 77603797 Local Court of Munich / Amtsgericht München Registered Office: Munich (Germany) / Sitz: München Managing Directors / Geschäftsführer: Peter Streit, Mike MacKinnon VAT ID / USt-IdNr.: DE288084869

11 years

2
1
0 / 0

CDI 1.2 tck challenge 1

by Emily Jiang

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

11 years

4
6
0 / 0

Re: [weld-dev] Validation on Alternative/Interceptor/Decorator mentioned in beans.xml

by Emily Jiang

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> 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> > 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 >> >> >> _______________________________________________ >> weld-dev mailing listweld-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang(a)apache.org > > > -- Thanks Emily ================= Emily Jiang ejiang(a)apache.org

11 years

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-dev May 2015