From emijiang6 at googlemail.com Wed May 6 11:38:53 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Wed, 6 May 2015 16:38:53 +0100 Subject: [weld-dev] CDI EJB Intergration on Weld Message-ID: I have a few questions on ejb integration on Weld. 1)Does Weld handle the instance creation for ejb (using injectionTarget.produce) or delegate the instance creation to EJB container? I guess Weld will create the instead as it can manage decorators. If not, how can decorators be managed? Please confirm. 2) When Weld creates the EJB instance, how can the other non-CDI aroundconstruct interceptors (such as the interceptors defined via ejb-jar.xml or @Interceptors) be passed in? I found out the WeldCreationContext and AroundConstructCallback but I cannot find anything mentioned in the weld reference doc. Is this the right plugin point? 3)If Weld creates the EJB instance, how can all interceptors (cdi style and ejb style) be invoked? Will the instance need to be passed back to EJB container together with all CDI interceptors (get hold of them via EjbEndpointServiceImpl.java) and EJB container needs to manage the interceptors being invoked? 4)In Weld spec, it says you must register the SessionBeanInterceptor as the inner most interceptor in the stack for all EJBS. Can you clarify what inner most means? Does this interceptor need to be the first EJB interceptor to be called or the last EJB interceptor to be invoked? -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150506/e5aa0d9b/attachment.html From jharting at redhat.com Thu May 7 03:22:00 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 07 May 2015 09:22:00 +0200 Subject: [weld-dev] CDI EJB Intergration on Weld In-Reply-To: References: Message-ID: <554B1298.5060500@redhat.com> Hi Emily, comments inline. On 05/06/2015 05:38 PM, Emily Jiang wrote: > I have a few questions on ejb integration on Weld. > > 1)Does Weld handle the instance creation for ejb (using > injectionTarget.produce) or delegate the instance creation to EJB > container? I guess Weld will create the instead as it can manage > decorators. If not, how can decorators be managed? Please confirm. Correct. Weld creates EJB instances using InjectionTarget.produce() > > 2) When Weld creates the EJB instance, how can the other non-CDI > aroundconstruct interceptors (such as the interceptors defined via > ejb-jar.xml or @Interceptors) be passed in? I found out the > WeldCreationContext and AroundConstructCallback but I cannot find > anything mentioned in the weld reference doc. Is this the right plugin > point? Correct, AroundConstructCallback is the API you need to use. The JavaDoc should be helpful. Let me know if anything is not clear. I'll add a note about it to the refdoc. > > 3)If Weld creates the EJB instance, how can all interceptors (cdi > style and ejb style) be invoked? Will the instance need to be passed > back to EJB container together with all CDI interceptors (get hold of > them via EjbEndpointServiceImpl.java) and EJB container needs to > manage the interceptors being invoked? For interception type other than @AroundConstruct we leave it up to the EJB implementation to handle interception. Information about CDI interceptors is exposed to the EJB implementation via EjbServices.registerInterceptors() > > 4)In Weld spec, it says you must register the SessionBeanInterceptor > as the inner most interceptor in the stack for all EJBS. Can you > clarify what inner most means? Does this interceptor need to be the > first EJB interceptor to be called or the last EJB interceptor to be > invoked? Not sure why it says inner most - it should be outer most instead that is it should be called as first so that the @RequestScope is available for the other interceptors called later in the chain. > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150507/8762141e/attachment.html From emijiang6 at googlemail.com Thu May 7 07:50:26 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Thu, 7 May 2015 12:50:26 +0100 Subject: [weld-dev] CDI 1.2 tck challenge 1 Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150507/f6d401ad/attachment.html From emijiang6 at googlemail.com Thu May 7 07:57:28 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Thu, 7 May 2015 12:57:28 +0100 Subject: [weld-dev] Validation on Alternative/Interceptor/Decorator mentioned in beans.xml In-Reply-To: <554711EB.3080407@redhat.com> References: <5541BCAB.6020305@redhat.com> <554711EB.3080407@redhat.com> Message-ID: 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 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 > 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 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 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 at apache.org >> >> >> _______________________________________________ >> weld-dev mailing listweld-dev at lists.jboss.orghttps://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/20150507/c13a6ba5/attachment-0001.html From jharting at redhat.com Thu May 7 10:51:43 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 07 May 2015 16:51:43 +0200 Subject: [weld-dev] Validation on Alternative/Interceptor/Decorator mentioned in beans.xml In-Reply-To: References: <5541BCAB.6020305@redhat.com> <554711EB.3080407@redhat.com> Message-ID: <554B7BFF.6070506@redhat.com> 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 > 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 >> > 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 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 >>> 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 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/20150507/c13c8280/attachment.html From jharting at redhat.com Thu May 7 11:02:22 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 07 May 2015 17:02:22 +0200 Subject: [weld-dev] CDI 1.2 tck challenge 1 In-Reply-To: References: Message-ID: <554B7E7E.60505@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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150507/205f2d2a/attachment.html From struberg at yahoo.de Thu May 7 13:29:02 2015 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 7 May 2015 19:29:02 +0200 Subject: [weld-dev] CDI 1.2 tck challenge 1 In-Reply-To: <554B7E7E.60505@redhat.com> References: <554B7E7E.60505@redhat.com> Message-ID: <52686AC9-AE17-49DE-BE41-FE8BE93A528F@yahoo.de> 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 : > > 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 From emijiang6 at googlemail.com Fri May 8 04:00:03 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Fri, 8 May 2015 09:00:03 +0100 Subject: [weld-dev] CDI 1.2 tck challenge 1 In-Reply-To: <52686AC9-AE17-49DE-BE41-FE8BE93A528F@yahoo.de> References: <554B7E7E.60505@redhat.com> <52686AC9-AE17-49DE-BE41-FE8BE93A528F@yahoo.de> Message-ID: 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 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 : > > > > 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 From emijiang6 at googlemail.com Fri May 8 06:29:30 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Fri, 8 May 2015 11:29:30 +0100 Subject: [weld-dev] CDI EJB Intergration on Weld In-Reply-To: <554B1298.5060500@redhat.com> References: <554B1298.5060500@redhat.com> Message-ID: Thank you Jozef for your helpful response! I have another clarification on the interceptors on JavaEE component classes. EE7 spec states the JavaEE component classes, listed in Table EE.5-1, need to support interceptors. Take servlet for an example, which methods can be intercepted? As the servlet classes are invoked by the container, according to CDI1.2 spec, it seems only service(ServletRequest, ServletResponse) can be intercepted. No other methods can be intercepted. Normally customer applications override doPost or doGet, but they cannot be intercepted. I cannot see any value of support interceptors on Servlet. Anything I missed? Thanks Emily On Thu, May 7, 2015 at 8:22 AM, Jozef Hartinger wrote: > Hi Emily, comments inline. > > On 05/06/2015 05:38 PM, Emily Jiang wrote: > > I have a few questions on ejb integration on Weld. > > 1)Does Weld handle the instance creation for ejb (using > injectionTarget.produce) or delegate the instance creation to EJB > container? I guess Weld will create the instead as it can manage > decorators. If not, how can decorators be managed? Please confirm. > > Correct. Weld creates EJB instances using InjectionTarget.produce() > > > 2) When Weld creates the EJB instance, how can the other non-CDI > aroundconstruct interceptors (such as the interceptors defined via > ejb-jar.xml or @Interceptors) be passed in? I found out the > WeldCreationContext and AroundConstructCallback but I cannot find anything > mentioned in the weld reference doc. Is this the right plugin point? > > Correct, AroundConstructCallback is the API you need to use. The JavaDoc > should be helpful. Let me know if anything is not clear. I'll add a note > about it to the refdoc. > > > 3)If Weld creates the EJB instance, how can all interceptors (cdi style > and ejb style) be invoked? Will the instance need to be passed back to EJB > container together with all CDI interceptors (get hold of them via > EjbEndpointServiceImpl.java) and EJB container needs to manage the > interceptors being invoked? > > For interception type other than @AroundConstruct we leave it up to the > EJB implementation to handle interception. Information about CDI > interceptors is exposed to the EJB implementation via > EjbServices.registerInterceptors() > > > 4)In Weld spec, it says you must register the SessionBeanInterceptor as > the inner most interceptor in the stack for all EJBS. Can you clarify what > inner most means? Does this interceptor need to be the first EJB > interceptor to be called or the last EJB interceptor to be invoked? > > Not sure why it says inner most - it should be outer most instead that is > it should be called as first so that the @RequestScope is available for the > other interceptors called later in the chain. > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > _______________________________________________ > weld-dev mailing listweld-dev at lists.jboss.orghttps://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/a7594e53/attachment.html From pmuir at redhat.com Fri May 8 07:21:47 2015 From: pmuir at redhat.com (Pete Muir) Date: Fri, 8 May 2015 12:21:47 +0100 Subject: [weld-dev] CDI 1.2 tck challenge 1 In-Reply-To: References: <554B7E7E.60505@redhat.com> <52686AC9-AE17-49DE-BE41-FE8BE93A528F@yahoo.de> Message-ID: 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 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 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 : > > > > 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 From emijiang6 at googlemail.com Sat May 9 16:44:39 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Sat, 9 May 2015 21:44:39 +0100 Subject: [weld-dev] CDI 1.2 tck challenge 1 In-Reply-To: References: <554B7E7E.60505@redhat.com> <52686AC9-AE17-49DE-BE41-FE8BE93A528F@yahoo.de> Message-ID: ah. ok. It makes sense. We will update our test framework. Thanks all! On Fri, May 8, 2015 at 12:21 PM, Pete Muir 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 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 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 : > > > > > > 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 From jharting at redhat.com Mon May 11 01:47:28 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 11 May 2015 07:47:28 +0200 Subject: [weld-dev] CDI 1.2 tck challenge 1 In-Reply-To: <52686AC9-AE17-49DE-BE41-FE8BE93A528F@yahoo.de> References: <554B7E7E.60505@redhat.com> <52686AC9-AE17-49DE-BE41-FE8BE93A528F@yahoo.de> Message-ID: <55504270.8050202@redhat.com> 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 : >> >> 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 From emijiang6 at googlemail.com Mon May 11 09:47:06 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 11 May 2015 14:47:06 +0100 Subject: [weld-dev] Interceptors Message-ID: 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 at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150511/a067f038/attachment.html From jharting at redhat.com Tue May 12 02:50:51 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 12 May 2015 08:50:51 +0200 Subject: [weld-dev] Interceptors In-Reply-To: References: Message-ID: <5551A2CB.6060206@redhat.com> On 05/11/2015 03:47 PM, Emily Jiang wrote: > > 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? Yes. It is not the very same creational context but a new one with a parent-child relationship to the one of the associated bean. This is the same as for @Dependent dependencies > Will Weld managed the cdi interceptors as well as the old-styled > interceptors? Yes, Weld manages interceptor bindings associated using interceptor bindings as well as those associated using @Interceptors > @Interceptors don't work on other cdi beans except ejb and managed > beans, right? "Managed bean" is ambiguous. Weld support interceptors on all CDI managed beans (not on producer fields/methods nor extension-provided beans). > > 2. Interceptors on ejb beans or managed beans > I think the integrator needs to create these @Interceptors and cdi > interceptors. Yes, for EJBs and EE managed beans it is integrator's job to handle those. Weld can handle @AroundConstruct interceptors if needed. I've updated the docs on this topic recently: https://github.com/jharting/core/blob/a1eb6194be36ded86dc9709c6767f5016fb98997/docs/reference/src/main/asciidoc/ri-spi.asciidoc#around-construct-interception > Will these interceptors use the non-contextual creational context > (scope @Dependent) or use the ejb or managed bean's creational context? 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? Any time the parent (bean's) creational context is destroyed, the children creational contexts (interceptors') are destroyed also by Weld. > > 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? This depends on how the component classes are managed. Assuming the components are managed using Weld-provided InjectionTarget then it is up to the integrator to decide whether it provides interception support or whether it should be provided by Weld. This can be configured for each InjectionTarget individually using this builder: http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldInjectionTargetBuilder.html > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150512/a4645aba/attachment.html From emijiang6 at googlemail.com Tue May 12 18:27:53 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Tue, 12 May 2015 23:27:53 +0100 Subject: [weld-dev] Interceptors In-Reply-To: <5551A2CB.6060206@redhat.com> References: <5551A2CB.6060206@redhat.com> Message-ID: Thank you Jozef for the helpful info. I have another question on interceptor: EE7 spec states the JavaEE component classes, listed in Table EE.5-1, need to support interceptors. Take servlet for an example, which methods can be intercepted? As the servlet classes are invoked by the container, according to CDI1.2 spec, it seems only service(ServletRequest, ServletResponse) can be intercepted. No other methods can be intercepted. Normally customer applications override doPost or doGet, but they cannot be intercepted. I cannot see any value of support interceptors on Servlet. Anything I missed? On Tue, May 12, 2015 at 7:50 AM, Jozef Hartinger wrote: > On 05/11/2015 03:47 PM, Emily Jiang wrote: > > > 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? > > Yes. It is not the very same creational context but a new one with a > parent-child relationship to the one of the associated bean. This is the > same as for @Dependent dependencies > > Will Weld managed the cdi interceptors as well as the old-styled > interceptors? > > Yes, Weld manages interceptor bindings associated using interceptor > bindings as well as those associated using @Interceptors > > @Interceptors don't work on other cdi beans except ejb and managed > beans, right? > > "Managed bean" is ambiguous. Weld support interceptors on all CDI managed > beans (not on producer fields/methods nor extension-provided beans). > > > 2. Interceptors on ejb beans or managed beans > I think the integrator needs to create these @Interceptors and cdi > interceptors. > > Yes, for EJBs and EE managed beans it is integrator's job to handle those. > Weld can handle @AroundConstruct interceptors if needed. I've updated the > docs on this topic recently: > https://github.com/jharting/core/blob/a1eb6194be36ded86dc9709c6767f5016fb98997/docs/reference/src/main/asciidoc/ri-spi.asciidoc#around-construct-interception > > Will these interceptors use the non-contextual creational context > (scope @Dependent) or use the ejb or managed bean's creational context? > > 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? > > Any time the parent (bean's) creational context is destroyed, the children > creational contexts (interceptors') are destroyed also by Weld. > > > 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? > > This depends on how the component classes are managed. Assuming the > components are managed using Weld-provided InjectionTarget then it is up to > the integrator to decide whether it provides interception support or > whether it should be provided by Weld. This can be configured for each > InjectionTarget individually using this builder: > http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldInjectionTargetBuilder.html > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > _______________________________________________ > weld-dev mailing listweld-dev at lists.jboss.orghttps://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/20150512/9bb00cc9/attachment-0001.html From emijiang6 at googlemail.com Tue May 12 18:35:12 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Tue, 12 May 2015 23:35:12 +0100 Subject: [weld-dev] CDI EJB Intergration on Weld In-Reply-To: References: <554B1298.5060500@redhat.com> Message-ID: A further question on EJB injection, In the Weld reference doc, performing injection on JavaEE component class: To help the integrator, Weld provides WeldManager.fireProcessInjectionTarget() which returns the InjectionTarget to use. The statement was not mentioned when it talks about performing injection on EJBs. My question is that do we need to call the above method to fire the event. Another observation with the code snippet on EJB section. It did not mention how the instance was created. I think 'it.produce()' needs to be there before the it.inject(). // Obtain the EjbDescriptor for the EJB // You may choose to use this utility method to get the descriptor EjbDescriptor ejbDescriptor = beanManager.getEjbDescriptor(ejbName); // Get an the Bean object Bean bean = beanManager.getBean(ejbDescriptor); // Create the injection target InjectionTarget it = deploymentBeanManager.createInjectionTarget(ejbDescriptor); // Per instance required, create the creational context CreationalContext cc = deploymentBeanManager.createCreationalContext(bean); *.... missing the line... Object instance = it.produce()* // Perform injection and call initializers it.inject(instance, cc); Thanks Emily On Fri, May 8, 2015 at 11:29 AM, Emily Jiang wrote: > Thank you Jozef for your helpful response! I have another clarification on > the interceptors on JavaEE component classes. > > EE7 spec states the JavaEE component classes, listed in Table EE.5-1, need > to support interceptors. Take servlet for an example, which methods can be > intercepted? > > As the servlet classes are invoked by the container, according to CDI1.2 > spec, it seems only service(ServletRequest, ServletResponse) can be > intercepted. No other methods can be intercepted. > > Normally customer applications override doPost or doGet, but they cannot > be intercepted. I cannot see any value of support interceptors on Servlet. > Anything I missed? > Thanks > Emily > > On Thu, May 7, 2015 at 8:22 AM, Jozef Hartinger > wrote: > >> Hi Emily, comments inline. >> >> On 05/06/2015 05:38 PM, Emily Jiang wrote: >> >> I have a few questions on ejb integration on Weld. >> >> 1)Does Weld handle the instance creation for ejb (using >> injectionTarget.produce) or delegate the instance creation to EJB >> container? I guess Weld will create the instead as it can manage >> decorators. If not, how can decorators be managed? Please confirm. >> >> Correct. Weld creates EJB instances using InjectionTarget.produce() >> >> >> 2) When Weld creates the EJB instance, how can the other non-CDI >> aroundconstruct interceptors (such as the interceptors defined via >> ejb-jar.xml or @Interceptors) be passed in? I found out the >> WeldCreationContext and AroundConstructCallback but I cannot find anything >> mentioned in the weld reference doc. Is this the right plugin point? >> >> Correct, AroundConstructCallback is the API you need to use. The JavaDoc >> should be helpful. Let me know if anything is not clear. I'll add a note >> about it to the refdoc. >> >> >> 3)If Weld creates the EJB instance, how can all interceptors (cdi style >> and ejb style) be invoked? Will the instance need to be passed back to EJB >> container together with all CDI interceptors (get hold of them via >> EjbEndpointServiceImpl.java) and EJB container needs to manage the >> interceptors being invoked? >> >> For interception type other than @AroundConstruct we leave it up to the >> EJB implementation to handle interception. Information about CDI >> interceptors is exposed to the EJB implementation via >> EjbServices.registerInterceptors() >> >> >> 4)In Weld spec, it says you must register the SessionBeanInterceptor as >> the inner most interceptor in the stack for all EJBS. Can you clarify what >> inner most means? Does this interceptor need to be the first EJB >> interceptor to be called or the last EJB interceptor to be invoked? >> >> Not sure why it says inner most - it should be outer most instead that is >> it should be called as first so that the @RequestScope is available for the >> other interceptors called later in the chain. >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> >> _______________________________________________ >> weld-dev mailing listweld-dev at lists.jboss.orghttps://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/20150512/f08feb98/attachment.html From maria.beurer at coriant.com Wed May 13 07:33:21 2015 From: maria.beurer at coriant.com (Beurer, Maria (Coriant - DE/Munich)) Date: Wed, 13 May 2015 11:33:21 +0000 Subject: [weld-dev] ECCN for weld Message-ID: 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 at 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 at coriant.com http://www.coriant.com [cid:image004.png at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150513/d3938308/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4008 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/weld-dev/attachments/20150513/d3938308/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 1183 bytes Desc: image002.png Url : http://lists.jboss.org/pipermail/weld-dev/attachments/20150513/d3938308/attachment-0003.png From mkouba at redhat.com Wed May 13 09:14:26 2015 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 13 May 2015 15:14:26 +0200 Subject: [weld-dev] ECCN for weld In-Reply-To: References: Message-ID: <55534E32.9010701@redhat.com> Hello, Weld 1.1.x is a part of Red Hat JBoss Enterprise Application Platform [1], of which the ECCN can be found in the product and technology matrix. I'm not sure about the project itself (i.e. if used outside the product). Martin [1] http://www.redhat.com/en/technologies/jboss-middleware/application-platform [2] http://www.redhat.com/en/about/export-control-product-matrix Dne 13.5.2015 v 13:33 Beurer, Maria (Coriant - DE/Munich) napsal(a): > 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 at 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 at coriant.com > http://www.coriant.com > cid:image004.png at 01D08645.87B02DC0Think 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 > > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Martin Kouba Software Engineer Red Hat, Czech Republic From emijiang6 at googlemail.com Thu May 14 17:47:20 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Thu, 14 May 2015 22:47:20 +0100 Subject: [weld-dev] Injection Services cannot handler producer on a static field Message-ID: 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 at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150514/615c908c/attachment.html From mkouba at redhat.com Fri May 15 05:27:02 2015 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 15 May 2015 11:27:02 +0200 Subject: [weld-dev] Injection Services cannot handler producer on a static field In-Reply-To: References: Message-ID: <5555BBE6.3070501@redhat.com> Hi Emily, for a static producer field there is no InjectionTarget (there's no instance to inject) and therefore no IT may be registered via InjectionServices. When using InjectionServices the current API does not allow to bypass the value of the static field and obtain the EE resource (e.g. do a JNDI lookup). So we let the integrator "inject" the static field, then read the value and propagate as the bean instance. Martin Dne 14.5.2015 v 23:47 Emily Jiang napsal(a): > > 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 at apache.org > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > From mkouba at redhat.com Fri May 15 06:45:54 2015 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 15 May 2015 12:45:54 +0200 Subject: [weld-dev] Interceptors In-Reply-To: References: <5551A2CB.6060206@redhat.com> Message-ID: <5555CE62.9020706@redhat.com> Dne 13.5.2015 v 00:27 Emily Jiang napsal(a): > Thank you Jozef for the helpful info. I have another question on > interceptor: > EE7 spec states the JavaEE component classes, listed in Table EE.5-1, > need to support interceptors. Take servlet for an example, which methods > can be intercepted? > > As the servlet classes are invoked by the container, according to CDI1.2 > spec, it seems only service(ServletRequest, ServletResponse) can be > intercepted. No other methods can be intercepted. > > Normally customer applications override doPost or doGet, but they cannot > be intercepted. I cannot see any value of support interceptors on > Servlet. Anything I missed? The serlet container always invokes Servlet.service(ServletRequest, ServletResponse)() which delegates to one of those convenient methods (doGet() etc.) in case of javax.servlet.http.HttpServlet. So if you extend HttpServlet and only override doGet() it would be "intercepted" if you annotate the servlet class with an interceptor binding. If you only annotate the doGet() method an interceptor will not be invoked. > > On Tue, May 12, 2015 at 7:50 AM, Jozef Hartinger > wrote: > > On 05/11/2015 03:47 PM, Emily Jiang wrote: >> >> 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? > Yes. It is not the very same creational context but a new one with a > parent-child relationship to the one of the associated bean. This is > the same as for @Dependent dependencies >> Will Weld managed the cdi interceptors as well as the old-styled >> interceptors? > Yes, Weld manages interceptor bindings associated using interceptor > bindings as well as those associated using @Interceptors >> @Interceptors don't work on other cdi beans except ejb and managed >> beans, right? > "Managed bean" is ambiguous. Weld support interceptors on all CDI > managed beans (not on producer fields/methods nor extension-provided > beans). >> >> 2. Interceptors on ejb beans or managed beans >> I think the integrator needs to create these @Interceptors and cdi >> interceptors. > Yes, for EJBs and EE managed beans it is integrator's job to handle > those. Weld can handle @AroundConstruct interceptors if needed. I've > updated the docs on this topic recently: > https://github.com/jharting/core/blob/a1eb6194be36ded86dc9709c6767f5016fb98997/docs/reference/src/main/asciidoc/ri-spi.asciidoc#around-construct-interception >> Will these interceptors use the non-contextual creational context >> (scope @Dependent) or use the ejb or managed bean's creational >> context? > 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? > Any time the parent (bean's) creational context is destroyed, the > children creational contexts (interceptors') are destroyed also by Weld. >> >> 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? > This depends on how the component classes are managed. Assuming the > components are managed using Weld-provided InjectionTarget then it > is up to the integrator to decide whether it provides interception > support or whether it should be provided by Weld. This can be > configured for each InjectionTarget individually using this builder: > http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldInjectionTargetBuilder.html >> >> >> -- >> 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 > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > From emijiang6 at googlemail.com Sat May 16 18:02:49 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Sat, 16 May 2015 23:02:49 +0100 Subject: [weld-dev] Interceptors In-Reply-To: <5555CE62.9020706@redhat.com> References: <5551A2CB.6060206@redhat.com> <5555CE62.9020706@redhat.com> Message-ID: Thank you Martin! I think if I specifiy a class level interceptor, service(ServiceRequest, ServletResponse) will be intercepted but not doGet(), as doGet will be called by .service(ServletRequest, ServletResponse) directly not via a proxy. Did I miss anything? On Fri, May 15, 2015 at 11:45 AM, Martin Kouba wrote: > Dne 13.5.2015 v 00:27 Emily Jiang napsal(a): > >> Thank you Jozef for the helpful info. I have another question on >> interceptor: >> EE7 spec states the JavaEE component classes, listed in Table EE.5-1, >> need to support interceptors. Take servlet for an example, which methods >> can be intercepted? >> >> As the servlet classes are invoked by the container, according to CDI1.2 >> spec, it seems only service(ServletRequest, ServletResponse) can be >> intercepted. No other methods can be intercepted. >> >> Normally customer applications override doPost or doGet, but they cannot >> be intercepted. I cannot see any value of support interceptors on >> Servlet. Anything I missed? >> > > The serlet container always invokes Servlet.service(ServletRequest, > ServletResponse)() which delegates to one of those convenient methods > (doGet() etc.) in case of javax.servlet.http.HttpServlet. So if you extend > HttpServlet and only override doGet() it would be "intercepted" if you > annotate the servlet class with an interceptor binding. If you only > annotate the doGet() method an interceptor will not be invoked. > > >> On Tue, May 12, 2015 at 7:50 AM, Jozef Hartinger > > wrote: >> >> On 05/11/2015 03:47 PM, Emily Jiang wrote: >> >>> >>> 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? >>> >> Yes. It is not the very same creational context but a new one with a >> parent-child relationship to the one of the associated bean. This is >> the same as for @Dependent dependencies >> >>> Will Weld managed the cdi interceptors as well as the old-styled >>> interceptors? >>> >> Yes, Weld manages interceptor bindings associated using interceptor >> bindings as well as those associated using @Interceptors >> >>> @Interceptors don't work on other cdi beans except ejb and managed >>> beans, right? >>> >> "Managed bean" is ambiguous. Weld support interceptors on all CDI >> managed beans (not on producer fields/methods nor extension-provided >> beans). >> >>> >>> 2. Interceptors on ejb beans or managed beans >>> I think the integrator needs to create these @Interceptors and cdi >>> interceptors. >>> >> Yes, for EJBs and EE managed beans it is integrator's job to handle >> those. Weld can handle @AroundConstruct interceptors if needed. I've >> updated the docs on this topic recently: >> >> https://github.com/jharting/core/blob/a1eb6194be36ded86dc9709c6767f5016fb98997/docs/reference/src/main/asciidoc/ri-spi.asciidoc#around-construct-interception >> >>> Will these interceptors use the non-contextual creational context >>> (scope @Dependent) or use the ejb or managed bean's creational >>> context? >>> >> 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? >>> >> Any time the parent (bean's) creational context is destroyed, the >> children creational contexts (interceptors') are destroyed also by >> Weld. >> >>> >>> 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? >>> >> This depends on how the component classes are managed. Assuming the >> components are managed using Weld-provided InjectionTarget then it >> is up to the integrator to decide whether it provides interception >> support or whether it should be provided by Weld. This can be >> configured for each InjectionTarget individually using this builder: >> >> http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldInjectionTargetBuilder.html >> >>> >>> >>> -- >>> 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 >> >> >> _______________________________________________ >> 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/20150516/ca22fb37/attachment-0001.html From mkouba at redhat.com Mon May 18 02:34:41 2015 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 18 May 2015 08:34:41 +0200 Subject: [weld-dev] Interceptors In-Reply-To: References: <5551A2CB.6060206@redhat.com> <5555CE62.9020706@redhat.com> Message-ID: <55598801.5000104@redhat.com> Dne 17.5.2015 v 00:02 Emily Jiang napsal(a): > Thank you Martin! I think if I specifiy a class level interceptor, > service(ServiceRequest, ServletResponse) will be intercepted but not > doGet(), as doGet will be called by .service(ServletRequest, > ServletResponse) directly not via a proxy. Did I miss anything? > Yes, the HttpServlet.doGet() invocation itself will not be intercepted, but the interceptor will be called for the "outer" service() method. So from the user point of view the result will be similar. > On Fri, May 15, 2015 at 11:45 AM, Martin Kouba > wrote: > > Dne 13.5.2015 v 00:27 Emily Jiang napsal(a): > > Thank you Jozef for the helpful info. I have another question on > interceptor: > EE7 spec states the JavaEE component classes, listed in Table > EE.5-1, > need to support interceptors. Take servlet for an example, which > methods > can be intercepted? > > As the servlet classes are invoked by the container, according > to CDI1.2 > spec, it seems only service(ServletRequest, ServletResponse) can be > intercepted. No other methods can be intercepted. > > Normally customer applications override doPost or doGet, but > they cannot > be intercepted. I cannot see any value of support interceptors on > Servlet. Anything I missed? > > > The serlet container always invokes Servlet.service(ServletRequest, > ServletResponse)() which delegates to one of those convenient > methods (doGet() etc.) in case of javax.servlet.http.HttpServlet. So > if you extend HttpServlet and only override doGet() it would be > "intercepted" if you annotate the servlet class with an interceptor > binding. If you only annotate the doGet() method an interceptor will > not be invoked. > > > On Tue, May 12, 2015 at 7:50 AM, Jozef Hartinger > > >> wrote: > > On 05/11/2015 03:47 PM, Emily Jiang wrote: > > > 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? > > Yes. It is not the very same creational context but a new > one with a > parent-child relationship to the one of the associated > bean. This is > the same as for @Dependent dependencies > > Will Weld managed the cdi interceptors as well as the > old-styled > interceptors? > > Yes, Weld manages interceptor bindings associated using > interceptor > bindings as well as those associated using @Interceptors > > @Interceptors don't work on other cdi beans except ejb > and managed > beans, right? > > "Managed bean" is ambiguous. Weld support interceptors on > all CDI > managed beans (not on producer fields/methods nor > extension-provided > beans). > > > 2. Interceptors on ejb beans or managed beans > I think the integrator needs to create these > @Interceptors and cdi > interceptors. > > Yes, for EJBs and EE managed beans it is integrator's job > to handle > those. Weld can handle @AroundConstruct interceptors if > needed. I've > updated the docs on this topic recently: > https://github.com/jharting/core/blob/a1eb6194be36ded86dc9709c6767f5016fb98997/docs/reference/src/main/asciidoc/ri-spi.asciidoc#around-construct-interception > > Will these interceptors use the non-contextual > creational context > (scope @Dependent) or use the ejb or managed bean's > creational > context? > > 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? > > Any time the parent (bean's) creational context is > destroyed, the > children creational contexts (interceptors') are destroyed > also by Weld. > > > 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? > > This depends on how the component classes are managed. > Assuming the > components are managed using Weld-provided InjectionTarget > then it > is up to the integrator to decide whether it provides > interception > support or whether it should be provided by Weld. This can be > configured for each InjectionTarget individually using this > builder: > http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldInjectionTargetBuilder.html > > > > -- > 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 > > > > > _______________________________________________ > 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 -- Martin Kouba Software Engineer Red Hat, Czech Republic From emijiang6 at googlemail.com Mon May 18 03:51:27 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 18 May 2015 08:51:27 +0100 Subject: [weld-dev] Java EE component class injection point validation In-Reply-To: <55599938.2050500@redhat.com> References: <55599938.2050500@redhat.com> Message-ID: oops. yes. Can you shed some lights on this problem? On Mon, May 18, 2015 at 8:48 AM, Martin Kouba wrote: > Emily, > > I believe this one belongs rather to the weld-dev ML. > > Martin > > Dne 18.5.2015 v 09:23 Emily Jiang napsal(a): > >> >> In CDI1.2 spec, section 5.5.7 >> If a Java EE component class supporting injection that is not a bean has >> an injection point of >> type InjectionPoint and qualifier @Default, the container automatically >> detects the problem >> and treats it as a definition error. >> >> How can I plugin this validation? Is there a callback spi I can use to >> validate the injection point on JavaEE component? This exception needs >> to be thrown during the application deployment. >> >> -- >> 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/20150518/0c601827/attachment.html From mkouba at redhat.com Mon May 18 04:02:18 2015 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 18 May 2015 10:02:18 +0200 Subject: [weld-dev] Java EE component class injection point validation In-Reply-To: References: <55599938.2050500@redhat.com> Message-ID: <55599C8A.8000606@redhat.com> Emily, I've looked at WildFly integration code and it makes use of org.jboss.weld.manager.api.WeldManager.createInjectionTargetBuilder(AnnotatedType) for EE components, i.e. delegates validation to weld implemetation. M Dne 18.5.2015 v 09:51 Emily Jiang napsal(a): > oops. yes. Can you shed some lights on this problem? > > On Mon, May 18, 2015 at 8:48 AM, Martin Kouba > wrote: > > Emily, > > I believe this one belongs rather to the weld-dev ML. > > Martin > > Dne 18.5.2015 v 09:23 Emily Jiang napsal(a): > > > In CDI1.2 spec, section 5.5.7 > If a Java EE component class supporting injection that is not a > bean has > an injection point of > type InjectionPoint and qualifier @Default, the container > automatically > detects the problem > and treats it as a definition error. > > How can I plugin this validation? Is there a callback spi I can > use to > validate the injection point on JavaEE component? This exception > needs > to be thrown during the application deployment. > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org -- Martin Kouba Software Engineer Red Hat, Czech Republic From emijiang6 at googlemail.com Mon May 18 05:38:30 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 18 May 2015 10:38:30 +0100 Subject: [weld-dev] Java EE component class injection point validation In-Reply-To: <55599C8A.8000606@redhat.com> References: <55599938.2050500@redhat.com> <55599C8A.8000606@redhat.com> Message-ID: Thank you Martin! I did an experiment with your suggestion. The org.jboss.weld.manager.api.WeldManager.createInjectionTargetBuilder(AnnotatedType) for EE components was called by us when an EE component class is instanciated so it is too late for the validation (I think this api is used for creating instances or I was wrong, please explain a bit more). The validation has to happen during weld WeldBootstrap.validateBeans(), so an DefinitionException should cause the deployment failure. On Mon, May 18, 2015 at 9:02 AM, Martin Kouba wrote: > Emily, > > I've looked at WildFly integration code and it makes use of > org.jboss.weld.manager.api.WeldManager.createInjectionTargetBuilder(AnnotatedType) > for EE components, i.e. delegates validation to weld implemetation. > > M > > Dne 18.5.2015 v 09:51 Emily Jiang napsal(a): > >> oops. yes. Can you shed some lights on this problem? >> >> On Mon, May 18, 2015 at 8:48 AM, Martin Kouba > > wrote: >> >> Emily, >> >> I believe this one belongs rather to the weld-dev ML. >> >> Martin >> >> Dne 18.5.2015 v 09:23 Emily Jiang napsal(a): >> >> >> In CDI1.2 spec, section 5.5.7 >> If a Java EE component class supporting injection that is not a >> bean has >> an injection point of >> type InjectionPoint and qualifier @Default, the container >> automatically >> detects the problem >> and treats it as a definition error. >> >> How can I plugin this validation? Is there a callback spi I can >> use to >> validate the injection point on JavaEE component? This exception >> needs >> to be thrown during the application deployment. >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> > >> >> >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150518/3ec1b0c6/attachment.html From mkouba at redhat.com Mon May 18 07:38:44 2015 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 18 May 2015 13:38:44 +0200 Subject: [weld-dev] Java EE component class injection point validation In-Reply-To: References: <55599938.2050500@redhat.com> <55599C8A.8000606@redhat.com> Message-ID: <5559CF44.3080609@redhat.com> I think you should create an InjectionTarget upfront, during EE component initialization (i.e. cache the IT for a component, similarly to how javax.enterprise.inject.spi.Unmanaged works) and before an EE component instance is instantiated. Martin Dne 18.5.2015 v 11:38 Emily Jiang napsal(a): > Thank you Martin! I did an experiment with your suggestion. The > org.jboss.weld.manager.api.WeldManager.createInjectionTargetBuilder(AnnotatedType) > for EE components was called by us when an EE component class is > instanciated so it is too late for the validation (I think this api is > used for creating instances or I was wrong, please explain a bit more). > The validation has to happen during weld WeldBootstrap.validateBeans(), > so an DefinitionException should cause the deployment failure. > > On Mon, May 18, 2015 at 9:02 AM, Martin Kouba > wrote: > > Emily, > > I've looked at WildFly integration code and it makes use of > org.jboss.weld.manager.api.WeldManager.createInjectionTargetBuilder(AnnotatedType) > for EE components, i.e. delegates validation to weld implemetation. > > M > > Dne 18.5.2015 v 09:51 Emily Jiang napsal(a): > > oops. yes. Can you shed some lights on this problem? > > On Mon, May 18, 2015 at 8:48 AM, Martin Kouba > >> wrote: > > Emily, > > I believe this one belongs rather to the weld-dev ML. > > Martin > > Dne 18.5.2015 v 09:23 Emily Jiang napsal(a): > > > In CDI1.2 spec, section 5.5.7 > If a Java EE component class supporting injection that > is not a > bean has > an injection point of > type InjectionPoint and qualifier @Default, the container > automatically > detects the problem > and treats it as a definition error. > > How can I plugin this validation? Is there a callback > spi I can > use to > validate the injection point on JavaEE component? This > exception > needs > to be thrown during the application deployment. > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > > >> > > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org -- Martin Kouba Software Engineer Red Hat, Czech Republic From jharting at redhat.com Thu May 21 08:25:27 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 21 May 2015 14:25:27 +0200 Subject: [weld-dev] CDI EJB Intergration on Weld In-Reply-To: References: <554B1298.5060500@redhat.com> Message-ID: <555DCEB7.4080409@redhat.com> On 05/13/2015 12:35 AM, Emily Jiang wrote: > A further question on EJB injection, > > In the Weld reference doc, performing injection on JavaEE component class: > To help the integrator, Weld provides > WeldManager.fireProcessInjectionTarget() which returns the > InjectionTarget to use. > > The statement was not mentioned when it talks about performing > injection on EJBs. My question is that do we need to call the above > method to fire the event. No, you only need to call this for non-contextual components. For session beans this is done by Weld automatically. > > Another observation with the code snippet on EJB section. It did not > mention how the instance was created. I think 'it.produce()' needs to > be there before the it.inject(). > > // Obtain the EjbDescriptor for the EJB > // You may choose to use this utility method to get the descriptor > EjbDescriptor ejbDescriptor = beanManager.getEjbDescriptor(ejbName); > // Get an the Bean object > Bean bean = beanManager.getBean(ejbDescriptor); > // Create the injection target > InjectionTarget it = > deploymentBeanManager.createInjectionTarget(ejbDescriptor); > // Per instance required, create the creational context > CreationalContext cc = > deploymentBeanManager.createCreationalContext(bean); > > *.... missing the line... Object instance = it.produce()* > // Perform injection and call initializers > it.inject(instance, cc); Yes, looks like the line is missing. > > Thanks > Emily > > > > On Fri, May 8, 2015 at 11:29 AM, Emily Jiang > wrote: > > Thank you Jozef for your helpful response! I have another > clarification on the interceptors on JavaEE component classes. > > EE7 spec states the JavaEE component classes, listed in Table > EE.5-1, need to support interceptors. Take servlet for an example, > which methods can be intercepted? > > As the servlet classes are invoked by the container, according to > CDI1.2 spec, it seems only service(ServletRequest, > ServletResponse) can be intercepted. No other methods can be > intercepted. > > Normally customer applications override doPost or doGet, but they > cannot be intercepted. I cannot see any value of support > interceptors on Servlet. Anything I missed? > Thanks > Emily > > On Thu, May 7, 2015 at 8:22 AM, Jozef Hartinger > > wrote: > > Hi Emily, comments inline. > > On 05/06/2015 05:38 PM, Emily Jiang wrote: >> I have a few questions on ejb integration on Weld. >> >> 1)Does Weld handle the instance creation for ejb (using >> injectionTarget.produce) or delegate the instance creation to >> EJB container? I guess Weld will create the instead as it can >> manage decorators. If not, how can decorators be managed? >> Please confirm. > Correct. Weld creates EJB instances using > InjectionTarget.produce() >> >> 2) When Weld creates the EJB instance, how can the other >> non-CDI aroundconstruct interceptors (such as the >> interceptors defined via ejb-jar.xml or @Interceptors) be >> passed in? I found out the WeldCreationContext and >> AroundConstructCallback but I cannot find anything mentioned >> in the weld reference doc. Is this the right plugin point? > Correct, AroundConstructCallback is the API you need to use. > The JavaDoc should be helpful. Let me know if anything is not > clear. I'll add a note about it to the refdoc. >> >> 3)If Weld creates the EJB instance, how can all interceptors >> (cdi style and ejb style) be invoked? Will the instance need >> to be passed back to EJB container together with all CDI >> interceptors (get hold of them via >> EjbEndpointServiceImpl.java) and EJB container needs to >> manage the interceptors being invoked? > For interception type other than @AroundConstruct we leave it > up to the EJB implementation to handle interception. > Information about CDI interceptors is exposed to the EJB > implementation via EjbServices.registerInterceptors() >> >> 4)In Weld spec, it says you must register the >> SessionBeanInterceptor as the inner most interceptor in the >> stack for all EJBS. Can you clarify what inner most means? >> Does this interceptor need to be the first EJB interceptor to >> be called or the last EJB interceptor to be invoked? > Not sure why it says inner most - it should be outer most > instead that is it should be called as first so that the > @RequestScope is available for the other interceptors called > later in the chain. >> >> >> -- >> 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/20150521/bb7773cd/attachment.html From emijiang6 at googlemail.com Fri May 22 04:55:50 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Fri, 22 May 2015 09:55:50 +0100 Subject: [weld-dev] Weld 2.2.x runs against CDI 1.1 cts vs. CDI 1.2 cts? Message-ID: 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 at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150522/bc2411e2/attachment.html From jharting at redhat.com Fri May 22 05:10:23 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 22 May 2015 11:10:23 +0200 Subject: [weld-dev] Weld 2.2.x runs against CDI 1.1 cts vs. CDI 1.2 cts? In-Reply-To: References: Message-ID: <555EF27F.7000609@redhat.com> Weld 2.2 should be run against CDI 1.2 TCK. There were changes between CDI 1.1 and 1.2 due to which it won't pass CDI 1.1 TCK entirely. On 05/22/2015 10:55 AM, Emily Jiang wrote: > 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 at apache.org > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150522/e2601d04/attachment.html From emijiang6 at googlemail.com Fri May 22 06:34:32 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Fri, 22 May 2015 11:34:32 +0100 Subject: [weld-dev] Weld 2.2.x runs against CDI 1.1 cts vs. CDI 1.2 cts? In-Reply-To: <555EF27F.7000609@redhat.com> References: <555EF27F.7000609@redhat.com> Message-ID: Thank you Jozef for your quick reply! On Fri, May 22, 2015 at 10:10 AM, Jozef Hartinger wrote: > Weld 2.2 should be run against CDI 1.2 TCK. There were changes between > CDI 1.1 and 1.2 due to which it won't pass CDI 1.1 TCK entirely. > > > On 05/22/2015 10:55 AM, Emily Jiang wrote: > > 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 at apache.org > > > _______________________________________________ > weld-dev mailing listweld-dev at lists.jboss.orghttps://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/20150522/1a33403b/attachment-0001.html From emijiang6 at googlemail.com Sun May 24 03:58:35 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Sun, 24 May 2015 08:58:35 +0100 Subject: [weld-dev] Unable to find java.lang.Integer in any bean archives Message-ID: I'm trying to run the cdi tck but got an error for the following test: In the test: org.jboss.cdi.tck.tests.definition.bean.custom.CustomBeanImplementationTest Method: arquillianBeforeClass Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-000817: Unable to find Bean Deployment Archive for class java.lang.Integer at org.jboss.weld.util.DeploymentStructures.getOrCreateBeanDeployment(DeploymentStructures.java:39) at org.jboss.weld.bootstrap.events.AbstractBeanDiscoveryEvent.getOrCreateBeanDeployment(AbstractBeanDiscoveryEvent.java:70) at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.processBean(AfterBeanDiscoveryImpl.java:86) at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:186) ... 15 more It seems that Custom bean was added by an extension but the bean implements Bean. Surely the java.lang.Interger should not be any bean archives. Can someone tell me what I might done wrong? Will integrator need to do something to cater for all of the java.x classes or Weld should handle this? -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150524/8241a5d9/attachment.html From emijiang6 at googlemail.com Sun May 24 10:21:46 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Sun, 24 May 2015 15:21:46 +0100 Subject: [weld-dev] cdi tck: org.jboss.cdi.tck.tests.context.application.event.ApplicationScopeEventMultiWarTest Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150524/567a5fd1/attachment.html From jharting at redhat.com Mon May 25 01:54:26 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 25 May 2015 07:54:26 +0200 Subject: [weld-dev] Unable to find java.lang.Integer in any bean archives In-Reply-To: References: Message-ID: <5562B912.8010605@redhat.com> Emily, see the JavaDoc here: http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/bootstrap/spi/Deployment.html#loadBeanDeploymentArchive-java.lang.Class- Specifically, it says: " If the deployment archive containing the given class is not currently a bean deployment archive, it must be added to the bean deployment archive graph and returned." Therefore, even though the given class is not part of an existing bean archive, it should be handled by the integrator, added to the bean archive graph and returned from the method. HTH, Jozef On 05/24/2015 09:58 AM, Emily Jiang wrote: > I'm trying to run the cdi tck but got an error for the following test: > In the test: > org.jboss.cdi.tck.tests.definition.bean.custom.CustomBeanImplementationTest > Method: arquillianBeforeClass > > > > Caused by: org.jboss.weld.exceptions.IllegalStateException: > WELD-000817: Unable to find Bean Deployment Archive for class > java.lang.Integer > at > org.jboss.weld.util.DeploymentStructures.getOrCreateBeanDeployment(DeploymentStructures.java:39) > at > org.jboss.weld.bootstrap.events.AbstractBeanDiscoveryEvent.getOrCreateBeanDeployment(AbstractBeanDiscoveryEvent.java:70) > at > org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.processBean(AfterBeanDiscoveryImpl.java:86) > at > org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:186) > ... 15 more > > It seems that Custom bean was added by an extension but the bean > implements Bean. Surely the java.lang.Interger should not be > any bean archives. Can someone tell me what I might done wrong? Will > integrator need to do something to cater for all of the java.x classes > or Weld should handle this? > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150525/b4f2b4ba/attachment.html From jharting at redhat.com Mon May 25 02:03:59 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 25 May 2015 08:03:59 +0200 Subject: [weld-dev] cdi tck: org.jboss.cdi.tck.tests.context.application.event.ApplicationScopeEventMultiWarTest In-Reply-To: References: Message-ID: <5562BB4F.7030104@redhat.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150525/43361cb4/attachment.html From jharting at redhat.com Mon May 25 02:53:45 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 25 May 2015 08:53:45 +0200 Subject: [weld-dev] Weld releases Message-ID: <5562C6F9.10706@redhat.com> Weld 3.0.0.Alpha9 and 2.2.12.Final have been released. http://weld.cdi-spec.org/download/ From emijiang6 at googlemail.com Mon May 25 04:31:31 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 25 May 2015 09:31:31 +0100 Subject: [weld-dev] cdi tck: org.jboss.cdi.tck.tests.context.application.event.ApplicationScopeEventMultiWarTest In-Reply-To: <5562BB4F.7030104@redhat.com> References: <5562BB4F.7030104@redhat.com> Message-ID: 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 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 listweld-dev at lists.jboss.orghttps://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/20150525/67bff1d7/attachment.html From emijiang6 at googlemail.com Mon May 25 05:07:20 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 25 May 2015 10:07:20 +0100 Subject: [weld-dev] Unable to find java.lang.Integer in any bean archives In-Reply-To: <5562B912.8010605@redhat.com> References: <5562B912.8010605@redhat.com> Message-ID: Thank you Jozef! I also figured this out after I debugged the case further and reread the javadoc. Would you recommend to create one bda for every given class (not app class) or we should design a special archive to hold all this kind of classes or it does not matter much? As for adding the bda to the graph, from my understanding, these classes should be visible to every other classes in the deployment. Therefore, this new bda should be accessible to all other bdas in this deployment, right? Thanks Emily On Mon, May 25, 2015 at 6:54 AM, Jozef Hartinger wrote: > Emily, > > see the JavaDoc here: > http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/bootstrap/spi/Deployment.html#loadBeanDeploymentArchive-java.lang.Class > - > > Specifically, it says: > > " If the deployment archive containing the given class is not currently a > bean deployment archive, it must be added to the bean deployment archive > graph and returned." > > Therefore, even though the given class is not part of an existing bean > archive, it should be handled by the integrator, added to the bean archive > graph and returned from the method. > > HTH, > > Jozef > > > On 05/24/2015 09:58 AM, Emily Jiang wrote: > > I'm trying to run the cdi tck but got an error for the following test: > In the test: > org.jboss.cdi.tck.tests.definition.bean.custom.CustomBeanImplementationTest > Method: arquillianBeforeClass > > > > Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-000817: > Unable to find Bean Deployment Archive for class java.lang.Integer > at > org.jboss.weld.util.DeploymentStructures.getOrCreateBeanDeployment(DeploymentStructures.java:39) > at > org.jboss.weld.bootstrap.events.AbstractBeanDiscoveryEvent.getOrCreateBeanDeployment(AbstractBeanDiscoveryEvent.java:70) > at > org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.processBean(AfterBeanDiscoveryImpl.java:86) > at > org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:186) > ... 15 more > > It seems that Custom bean was added by an extension but the bean > implements Bean. Surely the java.lang.Interger should not be any > bean archives. Can someone tell me what I might done wrong? Will integrator > need to do something to cater for all of the java.x classes or Weld should > handle this? > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > _______________________________________________ > weld-dev mailing listweld-dev at lists.jboss.orghttps://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/20150525/250d6e66/attachment.html From emijiang6 at googlemail.com Mon May 25 05:09:48 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 25 May 2015 10:09:48 +0100 Subject: [weld-dev] [cdi-tck] cdi tck: org.jboss.cdi.tck.tests.context.application.event.ApplicationScopeEventMultiWarTest In-Reply-To: <722870515.4153383.1432543197285.JavaMail.zimbra@redhat.com> References: <5562BB4F.7030104@redhat.com> <722870515.4153383.1432543197285.JavaMail.zimbra@redhat.com> Message-ID: Thank you Tom and Jozef! On Mon, May 25, 2015 at 9:39 AM, Tomas Remes wrote: > > Hi Emily, > > Yes I am already working on that. As I commented on the isssue. > > Thank's > Tom > > ----- Original Message ----- > From: "Emily Jiang" > To: "Jozef Hartinger" > Cc: "cdi-tck" , "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 From jharting at redhat.com Mon May 25 06:08:21 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 25 May 2015 12:08:21 +0200 Subject: [weld-dev] Unable to find java.lang.Integer in any bean archives In-Reply-To: References: <5562B912.8010605@redhat.com> Message-ID: <5562F495.70005@redhat.com> On 05/25/2015 11:07 AM, Emily Jiang wrote: > Thank you Jozef! I also figured this out after I debugged the case > further and reread the javadoc. Would you recommend to create one bda > for every given class (not app class) or we should design a special > archive to hold all this kind of classes or it does not matter much? You'll need to honor accessibility in these archives. Therefore, for example Integer and Long can share a single bean archive but e.g. a different class that is not accessible from Integer and Long needs to be put in a separate bean archive and accessibility of the classes needs to be reflected in the BDA graph. One option we use in WildFly for these additional bean archives is to have a bean archive per classloader. > > As for adding the bda to the graph, from my understanding, these > classes should be visible to every other classes in the deployment. > Therefore, this new bda should be accessible to all other bdas in this > deployment, right? Yes, it is true for this particular class. If however loadBeanDeploymentArchive() was called for a different class (e.g. for a class from a web archive's library jar that is not itself a bean archive) then, as such class is not necessarily accessible from every bean archive, neither should be the returned bean archive. > Thanks > Emily > > On Mon, May 25, 2015 at 6:54 AM, Jozef Hartinger > wrote: > > Emily, > > see the JavaDoc here: > http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/bootstrap/spi/Deployment.html#loadBeanDeploymentArchive-java.lang.Class- > > Specifically, it says: > > " If the deployment archive containing the given class is not > currently a bean deployment archive, it must be added to the bean > deployment archive graph and returned." > > Therefore, even though the given class is not part of an existing > bean archive, it should be handled by the integrator, added to the > bean archive graph and returned from the method. > > HTH, > > Jozef > > > On 05/24/2015 09:58 AM, Emily Jiang wrote: >> I'm trying to run the cdi tck but got an error for the following >> test: >> In the test: >> org.jboss.cdi.tck.tests.definition.bean.custom.CustomBeanImplementationTest >> Method: arquillianBeforeClass >> >> >> >> Caused by: org.jboss.weld.exceptions.IllegalStateException: >> WELD-000817: Unable to find Bean Deployment Archive for class >> java.lang.Integer >> at >> org.jboss.weld.util.DeploymentStructures.getOrCreateBeanDeployment(DeploymentStructures.java:39) >> at >> org.jboss.weld.bootstrap.events.AbstractBeanDiscoveryEvent.getOrCreateBeanDeployment(AbstractBeanDiscoveryEvent.java:70) >> at >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.processBean(AfterBeanDiscoveryImpl.java:86) >> at >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:186) >> ... 15 more >> >> It seems that Custom bean was added by an extension but the bean >> implements Bean. Surely the java.lang.Interger should >> not be any bean archives. Can someone tell me what I might done >> wrong? Will integrator need to do something to cater for all of >> the java.x classes or Weld should handle this? >> >> -- >> 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/20150525/ada8cb4f/attachment.html From jharting at redhat.com Mon May 25 06:26:56 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 25 May 2015 12:26:56 +0200 Subject: [weld-dev] Weld 2.3 Message-ID: <5562F8F0.6090906@redhat.com> 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 From emijiang6 at googlemail.com Tue May 26 19:04:05 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Wed, 27 May 2015 00:04:05 +0100 Subject: [weld-dev] CDI EJB Intergration on Weld In-Reply-To: <555DCEB7.4080409@redhat.com> References: <554B1298.5060500@redhat.com> <555DCEB7.4080409@redhat.com> Message-ID: Thank you Jozef for your help with clarifying this! By the way, for non-CDI interceptors, though EE7 spec lists these interceptors under the category of JavaEE component classes, I guess they are different from other other JavaEE component classes. For these interceptor instance creation, I guess we should not use injectiontarget.produce(). Am I right to say that we need to call into the correct constructor with the resolved arguments? On Thu, May 21, 2015 at 1:25 PM, Jozef Hartinger wrote: > On 05/13/2015 12:35 AM, Emily Jiang wrote: > > A further question on EJB injection, > > In the Weld reference doc, performing injection on JavaEE component class: > To help the integrator, Weld provides > WeldManager.fireProcessInjectionTarget() which returns the > InjectionTarget to use. > > The statement was not mentioned when it talks about performing injection > on EJBs. My question is that do we need to call the above method to fire > the event. > > No, you only need to call this for non-contextual components. For session > beans this is done by Weld automatically. > > > Another observation with the code snippet on EJB section. It did not > mention how the instance was created. I think 'it.produce()' needs to be > there before the it.inject(). > > // Obtain the EjbDescriptor for the EJB > // You may choose to use this utility method to get the descriptor > EjbDescriptor ejbDescriptor = beanManager.getEjbDescriptor(ejbName); > // Get an the Bean object > Bean bean = beanManager.getBean(ejbDescriptor); > // Create the injection target > InjectionTarget it = > deploymentBeanManager.createInjectionTarget(ejbDescriptor); > // Per instance required, create the creational context > CreationalContext cc = > deploymentBeanManager.createCreationalContext(bean); > > *.... missing the line... Object instance = it.produce()* > // Perform injection and call initializers > it.inject(instance, cc); > > Yes, looks like the line is missing. > > > Thanks > Emily > > > > On Fri, May 8, 2015 at 11:29 AM, Emily Jiang > wrote: > >> Thank you Jozef for your helpful response! I have another >> clarification on the interceptors on JavaEE component classes. >> >> EE7 spec states the JavaEE component classes, listed in Table EE.5-1, >> need to support interceptors. Take servlet for an example, which methods >> can be intercepted? >> >> As the servlet classes are invoked by the container, according to CDI1.2 >> spec, it seems only service(ServletRequest, ServletResponse) can be >> intercepted. No other methods can be intercepted. >> >> Normally customer applications override doPost or doGet, but they cannot >> be intercepted. I cannot see any value of support interceptors on Servlet. >> Anything I missed? >> Thanks >> Emily >> >> On Thu, May 7, 2015 at 8:22 AM, Jozef Hartinger >> wrote: >> >>> Hi Emily, comments inline. >>> >>> On 05/06/2015 05:38 PM, Emily Jiang wrote: >>> >>> I have a few questions on ejb integration on Weld. >>> >>> 1)Does Weld handle the instance creation for ejb (using >>> injectionTarget.produce) or delegate the instance creation to EJB >>> container? I guess Weld will create the instead as it can manage >>> decorators. If not, how can decorators be managed? Please confirm. >>> >>> Correct. Weld creates EJB instances using InjectionTarget.produce() >>> >>> >>> 2) When Weld creates the EJB instance, how can the other non-CDI >>> aroundconstruct interceptors (such as the interceptors defined via >>> ejb-jar.xml or @Interceptors) be passed in? I found out the >>> WeldCreationContext and AroundConstructCallback but I cannot find anything >>> mentioned in the weld reference doc. Is this the right plugin point? >>> >>> Correct, AroundConstructCallback is the API you need to use. The >>> JavaDoc should be helpful. Let me know if anything is not clear. I'll add a >>> note about it to the refdoc. >>> >>> >>> 3)If Weld creates the EJB instance, how can all interceptors (cdi style >>> and ejb style) be invoked? Will the instance need to be passed back to EJB >>> container together with all CDI interceptors (get hold of them via >>> EjbEndpointServiceImpl.java) and EJB container needs to manage the >>> interceptors being invoked? >>> >>> For interception type other than @AroundConstruct we leave it up to the >>> EJB implementation to handle interception. Information about CDI >>> interceptors is exposed to the EJB implementation via >>> EjbServices.registerInterceptors() >>> >>> >>> 4)In Weld spec, it says you must register the SessionBeanInterceptor as >>> the inner most interceptor in the stack for all EJBS. Can you clarify what >>> inner most means? Does this interceptor need to be the first EJB >>> interceptor to be called or the last EJB interceptor to be invoked? >>> >>> Not sure why it says inner most - it should be outer most instead that >>> is it should be called as first so that the @RequestScope is available for >>> the other interceptors called later in the chain. >>> >>> >>> >>> -- >>> Thanks >>> Emily >>> ================= >>> Emily Jiang >>> ejiang at apache.org >>> >>> >>> _______________________________________________ >>> weld-dev mailing listweld-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/weld-dev >>> >>> >>> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> > > > > -- > 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/20150527/4276b6fc/attachment-0001.html From emijiang6 at googlemail.com Tue May 26 19:12:52 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Wed, 27 May 2015 00:12:52 +0100 Subject: [weld-dev] annotations on Weld proxy classes Message-ID: It seems Weld proxy has the same annotations as the proxied class. However this conflicts with Bean validation spec as far as @Valid is concerned. This section of the bean validation spec is ending up in violation due to the duplicated annotation: ? One must not mark a method return value for cascaded validation more than once in a line of a class hierarchy. In other words, overriding methods on sub types (be it sub classes/interfaces or interface implementations) cannot mark the return value for cascaded validation if the return value has already been marked on the overridden method of the super type or interface. "The @Valid annotation is used to declare that a cascaded validation of the given method/constructor parameters or return values is performed by the Bean Validation provider. " Here is some debug added to the apache bean validation code that shows which two classes have the @Valid on the createValidEvent method: $$$$$$$$$$$$DEBUG clazz = class org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue$Proxy$_$$_WeldSubclass method = public org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.Event org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue$Proxy$_$$_WeldSubclass.createValidEvent() $$$$$$$$$$$$DEBUG clazz = class org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue method = public org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.Event org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue.createValidEvent() $$$$$$$$$$$$$$$$$DEBUG returnValid = 2 // number of hits having @Valid If I understand correctly, I think this annotation needs to be treated differently. -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150527/98ae6aa7/attachment.html From ooo_saturn7 at mail.ru Wed May 27 02:55:18 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Wed, 27 May 2015 09:55:18 +0300 Subject: [weld-dev] =?utf-8?q?CDI=3A_bean-discovery-mode=3Dannotated_is_ig?= =?utf-8?q?nored?= Message-ID: <1432709718.476308508@f358.i.mail.ru> I use weld as CDI container. Besides I use osgi (felix). So it's javase + felix+weld+pax. I have the following beans.xml And I have two classes: @ApplicationScopedpublicclass A {@Injectprivate B b;publicvoid postCreate(@ObservesContainerInitialized event,BundleContext ctx){ b.test();}} And class B publicclass B{publicvoid test(){System.out.println("test is here");}} As you see class B doesn't have any @scopes or @dependent annotations. However when I start application object of class B is injected to object A and method test is invoked. Why? As I understand it mustn't be injected. EDIT 1 I tried to use 1.1 version: but it didn't help. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150527/f6500a6b/attachment.html From mkouba at redhat.com Wed May 27 02:58:24 2015 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 27 May 2015 08:58:24 +0200 Subject: [weld-dev] annotations on Weld proxy classes In-Reply-To: References: Message-ID: <55656B10.9080109@redhat.com> FYI this is not the only problem with Bean Validation and CDI client proxies. See also my last comment on CDI-10 [1] and the question posted on the HV forum [2]. Martin [1] https://issues.jboss.org/browse/CDI-10?focusedCommentId=13069965&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13069965 [2] https://forum.hibernate.org/viewtopic.php?f=26&t=1039523 Dne 27.5.2015 v 01:12 Emily Jiang napsal(a): > It seems Weld proxy has the same annotations as the proxied class. > However this conflicts with Bean validation spec as far as @Valid is > concerned. > > > This section of the bean validation spec is ending up in violation due > to the duplicated annotation: > ? One must not mark a method return value for cascaded validation more > than once in a line of a class hierarchy. > In other words, overriding methods on sub types (be it sub > classes/interfaces or interface implementations) cannot mark the return > value for cascaded validation if the return value has already been > marked on the overridden method of the super type or interface. > > "The @Valid annotation is used to declare that a cascaded validation of > the given method/constructor parameters or > return values is performed by the Bean Validation provider. " > > > Here is some debug added to the apache bean validation code that shows > which two classes have the @Valid on the createValidEvent method: > > $$$$$$$$$$$$DEBUG clazz = class > org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue$Proxy$_$$_WeldSubclass > method = public > org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.Event > org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue$Proxy$_$$_WeldSubclass.createValidEvent() > $$$$$$$$$$$$DEBUG clazz = class > org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue > method = public > org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.Event > org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue.createValidEvent() > $$$$$$$$$$$$$$$$$DEBUG returnValid = 2 // number of hits having @Valid > > If I understand correctly, I think this annotation needs to be treated > differently. > -- > 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 > -- Martin Kouba Software Engineer Red Hat, Czech Republic From jharting at redhat.com Wed May 27 03:30:50 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 27 May 2015 09:30:50 +0200 Subject: [weld-dev] annotations on Weld proxy classes In-Reply-To: References: Message-ID: <556572AA.1060909@redhat.com> Hi Emily, you're right, methods of a subclass generated by Weld have the same annotations applied as the original class. This behavior is depended on by framework/extension authors therefore we cannot change that. The BV spec / apache bean validation check seems too strict to me. The purpose of the constraint is to make sure that the postcondition constraints are not weaker in a subtype (e.g. a subtype could define @Valid with a strict subset of constraints in an overridden method). That sounds reasonable in general. In this particular case however, since Weld copies all the annotations, the constraint set is the same. The check could perhaps be altered to not fail if the constraint sets are equal. Alternatively, the BV implementation would need to recognize that this is a Weld proxy and not fail on cascaded validation in such case. Jozef On 05/27/2015 01:12 AM, Emily Jiang wrote: > > It seems Weld proxy has the same annotations as the proxied class. > However this conflicts with Bean validation spec as far as @Valid is > concerned. > > > This section of the bean validation spec is ending up in violation due > to the duplicated annotation: > ? One must not mark a method return value for cascaded validation more > than once in a line of a class hierarchy. > In other words, overriding methods on sub types (be it sub > classes/interfaces or interface implementations) cannot mark the > return value for cascaded validation if the return value has already > been marked on the overridden method of the super type or interface. > > "The @Valid annotation is used to declare that a cascaded validation > of the given method/constructor parameters or > return values is performed by the Bean Validation provider. " > > > Here is some debug added to the apache bean validation code that shows > which two classes have the @Valid on the createValidEvent method: > > $$$$$$$$$$$$DEBUG clazz = class > org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue$Proxy$_$$_WeldSubclass > method = public > org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.Event org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue$Proxy$_$$_WeldSubclass.createValidEvent() > $$$$$$$$$$$$DEBUG clazz = class > org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue > method = public > org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.Event org.hibernate.beanvalidation.tck.tests.integration.cdi.executable.CalendarServiceWithCascadingReturnValue.createValidEvent() > $$$$$$$$$$$$$$$$$DEBUG returnValid = 2 // number of hits having @Valid > > If I understand correctly, I think this annotation needs to be treated > differently. > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150527/a33f774c/attachment-0001.html From jharting at redhat.com Wed May 27 04:00:34 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 27 May 2015 10:00:34 +0200 Subject: [weld-dev] CDI EJB Intergration on Weld In-Reply-To: References: <554B1298.5060500@redhat.com> <555DCEB7.4080409@redhat.com> Message-ID: <556579A2.2090808@redhat.com> You can use InjectionTarget.produce() to create instances of non-CDI interceptors as well. The implementation will call the @Inject constructor passing in the dependencies or call the no-arg constructor. What "correct constructor with the resolved arguments" did you mean? Jozef On 05/27/2015 01:04 AM, Emily Jiang wrote: > Thank you Jozef for your help with clarifying this! > > By the way, for non-CDI interceptors, though EE7 spec lists these > interceptors under the category of JavaEE component classes, I guess > they are different from other other JavaEE component classes. For > these interceptor instance creation, I guess we should not use > injectiontarget.produce(). Am I right to say that we need to call into > the correct constructor with the resolved arguments? > > On Thu, May 21, 2015 at 1:25 PM, Jozef Hartinger > wrote: > > On 05/13/2015 12:35 AM, Emily Jiang wrote: >> A further question on EJB injection, >> >> In the Weld reference doc, performing injection on JavaEE >> component class: >> To help the integrator, Weld provides >> WeldManager.fireProcessInjectionTarget() which returns the >> InjectionTarget to use. >> >> The statement was not mentioned when it talks about performing >> injection on EJBs. My question is that do we need to call the >> above method to fire the event. > No, you only need to call this for non-contextual components. For > session beans this is done by Weld automatically. >> >> Another observation with the code snippet on EJB section. It did >> not mention how the instance was created. I think 'it.produce()' >> needs to be there before the it.inject(). >> >> // Obtain the EjbDescriptor for the EJB >> // You may choose to use this utility method to get the descriptor >> EjbDescriptor ejbDescriptor = >> beanManager.getEjbDescriptor(ejbName); >> // Get an the Bean object >> Bean bean = beanManager.getBean(ejbDescriptor); >> // Create the injection target >> InjectionTarget it = >> deploymentBeanManager.createInjectionTarget(ejbDescriptor); >> // Per instance required, create the creational context >> CreationalContext cc = >> deploymentBeanManager.createCreationalContext(bean); >> >> *.... missing the line... Object instance = it.produce()* >> // Perform injection and call initializers >> it.inject(instance, cc); > Yes, looks like the line is missing. > >> >> Thanks >> Emily >> >> >> >> On Fri, May 8, 2015 at 11:29 AM, Emily Jiang >> > wrote: >> >> Thank you Jozef for your helpful response! I have another >> clarification on the interceptors on JavaEE component classes. >> >> EE7 spec states the JavaEE component classes, listed in Table >> EE.5-1, need to support interceptors. Take servlet for an >> example, which methods can be intercepted? >> >> As the servlet classes are invoked by the container, >> according to CDI1.2 spec, it seems only >> service(ServletRequest, ServletResponse) can be intercepted. >> No other methods can be intercepted. >> >> Normally customer applications override doPost or doGet, but >> they cannot be intercepted. I cannot see any value of support >> interceptors on Servlet. Anything I missed? >> Thanks >> Emily >> >> On Thu, May 7, 2015 at 8:22 AM, Jozef Hartinger >> > wrote: >> >> Hi Emily, comments inline. >> >> On 05/06/2015 05:38 PM, Emily Jiang wrote: >>> I have a few questions on ejb integration on Weld. >>> >>> 1)Does Weld handle the instance creation for ejb (using >>> injectionTarget.produce) or delegate the instance >>> creation to EJB container? I guess Weld will create the >>> instead as it can manage decorators. If not, how can >>> decorators be managed? Please confirm. >> Correct. Weld creates EJB instances using >> InjectionTarget.produce() >>> >>> 2) When Weld creates the EJB instance, how can the other >>> non-CDI aroundconstruct interceptors (such as the >>> interceptors defined via ejb-jar.xml or @Interceptors) >>> be passed in? I found out the WeldCreationContext and >>> AroundConstructCallback but I cannot find anything >>> mentioned in the weld reference doc. Is this the right >>> plugin point? >> Correct, AroundConstructCallback is the API you need to >> use. The JavaDoc should be helpful. Let me know if >> anything is not clear. I'll add a note about it to the >> refdoc. >>> >>> 3)If Weld creates the EJB instance, how can all >>> interceptors (cdi style and ejb style) be invoked? Will >>> the instance need to be passed back to EJB container >>> together with all CDI interceptors (get hold of them via >>> EjbEndpointServiceImpl.java) and EJB container needs to >>> manage the interceptors being invoked? >> For interception type other than @AroundConstruct we >> leave it up to the EJB implementation to handle >> interception. Information about CDI interceptors is >> exposed to the EJB implementation via >> EjbServices.registerInterceptors() >>> >>> 4)In Weld spec, it says you must register the >>> SessionBeanInterceptor as the inner most interceptor in >>> the stack for all EJBS. Can you clarify what inner most >>> means? Does this interceptor need to be the first EJB >>> interceptor to be called or the last EJB interceptor to >>> be invoked? >> Not sure why it says inner most - it should be outer most >> instead that is it should be called as first so that the >> @RequestScope is available for the other interceptors >> called later in the chain. >>> >>> >>> -- >>> 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 > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150527/e88ea9d2/attachment.html From jharting at redhat.com Wed May 27 04:21:06 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 27 May 2015 10:21:06 +0200 Subject: [weld-dev] CDI: bean-discovery-mode=annotated is ignored In-Reply-To: <1432709718.476308508@f358.i.mail.ru> References: <1432709718.476308508@f358.i.mail.ru> Message-ID: <55657E72.9030102@redhat.com> It seems that Pax CDI only implements explicit bean archives so far. I filed an issue at https://ops4j1.jira.com/browse/PAXCDI-186 You'll need to mark classes/packages you do not want discovered with @Vetoed or use an exclude filter http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#exclude_filters On 05/27/2015 08:55 AM, ????????? ???????? wrote: > > I use weld as CDI container. Besides I use osgi (felix). So it's > javase + felix+weld+pax. I have the following beans.xml > > | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd" > bean-discovery-mode="annotated">| > > And I have two classes: > > |@ApplicationScopedpublicclass A{@Injectprivate B b;publicvoid postCreate(@ObservesContainerInitialized event,BundleContext ctx){ > b.test();}}| > > And class B > > |publicclass B{publicvoid test(){System.out.println("test is here");}}| > > As you see class B doesn't have any @scopes or @dependent annotations. > However when I start application object of class B is injected to > object A and method test is invoked. Why? As I understand it mustn't > be injected. > > *EDIT 1* > I tried to use 1.1 version: > > | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee > http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd" > bean-discovery-mode="annotated" version="1.1">| > > but it didn't help. > > > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150527/7a6e6e5b/attachment-0001.html From emijiang6 at googlemail.com Wed May 27 04:43:03 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Wed, 27 May 2015 09:43:03 +0100 Subject: [weld-dev] CDI EJB Intergration on Weld In-Reply-To: <556579A2.2090808@redhat.com> References: <554B1298.5060500@redhat.com> <555DCEB7.4080409@redhat.com> <556579A2.2090808@redhat.com> Message-ID: Will the injectionTarget.produce() produces a Weld proxy for the non-CDI interceptors then? It seems ejb tck complains about the proxied non-CDI interceptors. I looked at the cdi interceptors and I think the instances are real objects not a proxy. What I meant of "correct constructor with the resolved arguments" is that I directly call into the correct non-CDI interceptors and get a real object instead of a proxy. On Wed, May 27, 2015 at 9:00 AM, Jozef Hartinger wrote: > You can use InjectionTarget.produce() to create instances of non-CDI > interceptors as well. The implementation will call the @Inject constructor > passing in the dependencies or call the no-arg constructor. What "correct > constructor with the resolved arguments" did you mean? > > Jozef > > > On 05/27/2015 01:04 AM, Emily Jiang wrote: > > Thank you Jozef for your help with clarifying this! > > By the way, for non-CDI interceptors, though EE7 spec lists these > interceptors under the category of JavaEE component classes, I guess they > are different from other other JavaEE component classes. For these > interceptor instance creation, I guess we should not use > injectiontarget.produce(). Am I right to say that we need to call into the > correct constructor with the resolved arguments? > > On Thu, May 21, 2015 at 1:25 PM, Jozef Hartinger > wrote: > >> On 05/13/2015 12:35 AM, Emily Jiang wrote: >> >> A further question on EJB injection, >> >> In the Weld reference doc, performing injection on JavaEE component class: >> To help the integrator, Weld provides >> WeldManager.fireProcessInjectionTarget() which returns the >> InjectionTarget to use. >> >> The statement was not mentioned when it talks about performing injection >> on EJBs. My question is that do we need to call the above method to fire >> the event. >> >> No, you only need to call this for non-contextual components. For >> session beans this is done by Weld automatically. >> >> >> Another observation with the code snippet on EJB section. It did not >> mention how the instance was created. I think 'it.produce()' needs to be >> there before the it.inject(). >> >> // Obtain the EjbDescriptor for the EJB >> // You may choose to use this utility method to get the descriptor >> EjbDescriptor ejbDescriptor = beanManager.getEjbDescriptor(ejbName); >> // Get an the Bean object >> Bean bean = beanManager.getBean(ejbDescriptor); >> // Create the injection target >> InjectionTarget it = >> deploymentBeanManager.createInjectionTarget(ejbDescriptor); >> // Per instance required, create the creational context >> CreationalContext cc = >> deploymentBeanManager.createCreationalContext(bean); >> >> *.... missing the line... Object instance = it.produce()* >> // Perform injection and call initializers >> it.inject(instance, cc); >> >> Yes, looks like the line is missing. >> >> >> Thanks >> Emily >> >> >> >> On Fri, May 8, 2015 at 11:29 AM, Emily Jiang >> wrote: >> >>> Thank you Jozef for your helpful response! I have another >>> clarification on the interceptors on JavaEE component classes. >>> >>> EE7 spec states the JavaEE component classes, listed in Table EE.5-1, >>> need to support interceptors. Take servlet for an example, which methods >>> can be intercepted? >>> >>> As the servlet classes are invoked by the container, according to >>> CDI1.2 spec, it seems only service(ServletRequest, ServletResponse) can be >>> intercepted. No other methods can be intercepted. >>> >>> Normally customer applications override doPost or doGet, but they cannot >>> be intercepted. I cannot see any value of support interceptors on Servlet. >>> Anything I missed? >>> Thanks >>> Emily >>> >>> On Thu, May 7, 2015 at 8:22 AM, Jozef Hartinger >>> wrote: >>> >>>> Hi Emily, comments inline. >>>> >>>> On 05/06/2015 05:38 PM, Emily Jiang wrote: >>>> >>>> I have a few questions on ejb integration on Weld. >>>> >>>> 1)Does Weld handle the instance creation for ejb (using >>>> injectionTarget.produce) or delegate the instance creation to EJB >>>> container? I guess Weld will create the instead as it can manage >>>> decorators. If not, how can decorators be managed? Please confirm. >>>> >>>> Correct. Weld creates EJB instances using InjectionTarget.produce() >>>> >>>> >>>> 2) When Weld creates the EJB instance, how can the other non-CDI >>>> aroundconstruct interceptors (such as the interceptors defined via >>>> ejb-jar.xml or @Interceptors) be passed in? I found out the >>>> WeldCreationContext and AroundConstructCallback but I cannot find anything >>>> mentioned in the weld reference doc. Is this the right plugin point? >>>> >>>> Correct, AroundConstructCallback is the API you need to use. The >>>> JavaDoc should be helpful. Let me know if anything is not clear. I'll add a >>>> note about it to the refdoc. >>>> >>>> >>>> 3)If Weld creates the EJB instance, how can all interceptors (cdi >>>> style and ejb style) be invoked? Will the instance need to be passed back >>>> to EJB container together with all CDI interceptors (get hold of them via >>>> EjbEndpointServiceImpl.java) and EJB container needs to manage the >>>> interceptors being invoked? >>>> >>>> For interception type other than @AroundConstruct we leave it up to >>>> the EJB implementation to handle interception. Information about CDI >>>> interceptors is exposed to the EJB implementation via >>>> EjbServices.registerInterceptors() >>>> >>>> >>>> 4)In Weld spec, it says you must register the SessionBeanInterceptor >>>> as the inner most interceptor in the stack for all EJBS. Can you clarify >>>> what inner most means? Does this interceptor need to be the first EJB >>>> interceptor to be called or the last EJB interceptor to be invoked? >>>> >>>> Not sure why it says inner most - it should be outer most instead that >>>> is it should be called as first so that the @RequestScope is available for >>>> the other interceptors called later in the chain. >>>> >>>> >>>> >>>> -- >>>> Thanks >>>> Emily >>>> ================= >>>> Emily Jiang >>>> ejiang at apache.org >>>> >>>> >>>> _______________________________________________ >>>> weld-dev mailing listweld-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/weld-dev >>>> >>>> >>>> >>> >>> >>> -- >>> Thanks >>> Emily >>> ================= >>> Emily Jiang >>> ejiang at apache.org >>> >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> >> > > > -- > 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/20150527/e0bf8f85/attachment-0001.html From jharting at redhat.com Wed May 27 05:27:39 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 27 May 2015 11:27:39 +0200 Subject: [weld-dev] CDI EJB Intergration on Weld In-Reply-To: References: <554B1298.5060500@redhat.com> <555DCEB7.4080409@redhat.com> <556579A2.2090808@redhat.com> Message-ID: <55658E0B.2000707@redhat.com> No, proxies/subclasses should not be used for non-CDI interceptors. This depends on which InjectionTarget you use to produce the instances. There is a special method on InjectionTargetFactory that should be used to create InjectionTargets for non-CDI interceptors http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldInjectionTargetFactory.html#createInterceptorInjectionTarget-- This special treatment is needed as otherwise the InjectionTarget would create a standard component instance (possibly intercepted), not intercepting. On 05/27/2015 10:43 AM, Emily Jiang wrote: > Will the injectionTarget.produce() produces a Weld proxy for the > non-CDI interceptors then? It seems ejb tck complains about the > proxied non-CDI interceptors. I looked at the cdi interceptors and I > think the instances are real objects not a proxy. > > What I meant of "correct constructor with the resolved arguments" is > that I directly call into the correct non-CDI interceptors and get a > real object instead of a proxy. > > On Wed, May 27, 2015 at 9:00 AM, Jozef Hartinger > wrote: > > You can use InjectionTarget.produce() to create instances of > non-CDI interceptors as well. The implementation will call the > @Inject constructor passing in the dependencies or call the no-arg > constructor. What "correct constructor with the resolved > arguments" did you mean? > > Jozef > > > On 05/27/2015 01:04 AM, Emily Jiang wrote: >> Thank you Jozef for your help with clarifying this! >> >> By the way, for non-CDI interceptors, though EE7 spec lists these >> interceptors under the category of JavaEE component classes, I >> guess they are different from other other JavaEE component >> classes. For these interceptor instance creation, I guess we >> should not use injectiontarget.produce(). Am I right to say that >> we need to call into the correct constructor with the resolved >> arguments? >> >> On Thu, May 21, 2015 at 1:25 PM, Jozef Hartinger >> > wrote: >> >> On 05/13/2015 12:35 AM, Emily Jiang wrote: >>> A further question on EJB injection, >>> >>> In the Weld reference doc, performing injection on JavaEE >>> component class: >>> To help the integrator, Weld provides >>> WeldManager.fireProcessInjectionTarget() which returns the >>> InjectionTarget to use. >>> >>> The statement was not mentioned when it talks about >>> performing injection on EJBs. My question is that do we need >>> to call the above method to fire the event. >> No, you only need to call this for non-contextual components. >> For session beans this is done by Weld automatically. >>> >>> Another observation with the code snippet on EJB section. It >>> did not mention how the instance was created. I think >>> 'it.produce()' needs to be there before the it.inject(). >>> >>> // Obtain the EjbDescriptor for the EJB >>> // You may choose to use this utility method to get the >>> descriptor >>> EjbDescriptor ejbDescriptor = >>> beanManager.getEjbDescriptor(ejbName); >>> // Get an the Bean object >>> Bean bean = beanManager.getBean(ejbDescriptor); >>> // Create the injection target >>> InjectionTarget it = >>> deploymentBeanManager.createInjectionTarget(ejbDescriptor); >>> // Per instance required, create the creational context >>> CreationalContext cc = >>> deploymentBeanManager.createCreationalContext(bean); >>> >>> *.... missing the line... Object instance = it.produce()* >>> // Perform injection and call initializers >>> it.inject(instance, cc); >> Yes, looks like the line is missing. >> >>> >>> Thanks >>> Emily >>> >>> >>> >>> On Fri, May 8, 2015 at 11:29 AM, Emily Jiang >>> > >>> wrote: >>> >>> Thank you Jozef for your helpful response! I have >>> another clarification on the interceptors on JavaEE >>> component classes. >>> >>> EE7 spec states the JavaEE component classes, listed in >>> Table EE.5-1, need to support interceptors. Take servlet >>> for an example, which methods can be intercepted? >>> >>> As the servlet classes are invoked by the container, >>> according to CDI1.2 spec, it seems only >>> service(ServletRequest, ServletResponse) can be >>> intercepted. No other methods can be intercepted. >>> >>> Normally customer applications override doPost or doGet, >>> but they cannot be intercepted. I cannot see any value >>> of support interceptors on Servlet. Anything I missed? >>> Thanks >>> Emily >>> >>> On Thu, May 7, 2015 at 8:22 AM, Jozef Hartinger >>> > wrote: >>> >>> Hi Emily, comments inline. >>> >>> On 05/06/2015 05:38 PM, Emily Jiang wrote: >>>> I have a few questions on ejb integration on Weld. >>>> >>>> 1)Does Weld handle the instance creation for ejb >>>> (using injectionTarget.produce) or delegate the >>>> instance creation to EJB container? I guess Weld >>>> will create the instead as it can manage >>>> decorators. If not, how can decorators be managed? >>>> Please confirm. >>> Correct. Weld creates EJB instances using >>> InjectionTarget.produce() >>>> >>>> 2) When Weld creates the EJB instance, how can the >>>> other non-CDI aroundconstruct interceptors (such as >>>> the interceptors defined via ejb-jar.xml or >>>> @Interceptors) be passed in? I found out the >>>> WeldCreationContext and AroundConstructCallback but >>>> I cannot find anything mentioned in the weld >>>> reference doc. Is this the right plugin point? >>> Correct, AroundConstructCallback is the API you need >>> to use. The JavaDoc should be helpful. Let me know >>> if anything is not clear. I'll add a note about it >>> to the refdoc. >>>> >>>> 3)If Weld creates the EJB instance, how can all >>>> interceptors (cdi style and ejb style) be invoked? >>>> Will the instance need to be passed back to EJB >>>> container together with all CDI interceptors (get >>>> hold of them via EjbEndpointServiceImpl.java) and >>>> EJB container needs to manage the interceptors >>>> being invoked? >>> For interception type other than @AroundConstruct we >>> leave it up to the EJB implementation to handle >>> interception. Information about CDI interceptors is >>> exposed to the EJB implementation via >>> EjbServices.registerInterceptors() >>>> >>>> 4)In Weld spec, it says you must register the >>>> SessionBeanInterceptor as the inner most >>>> interceptor in the stack for all EJBS. Can you >>>> clarify what inner most means? Does this >>>> interceptor need to be the first EJB interceptor to >>>> be called or the last EJB interceptor to be invoked? >>> Not sure why it says inner most - it should be outer >>> most instead that is it should be called as first so >>> that the @RequestScope is available for the other >>> interceptors called later in the chain. >>>> >>>> >>>> -- >>>> 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 >> >> >> >> >> -- >> 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/20150527/02f635d0/attachment-0001.html From emijiang6 at googlemail.com Wed May 27 10:22:28 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Wed, 27 May 2015 15:22:28 +0100 Subject: [weld-dev] Java EE component class injection point validation In-Reply-To: <5559CF44.3080609@redhat.com> References: <55599938.2050500@redhat.com> <55599C8A.8000606@redhat.com> <5559CF44.3080609@redhat.com> Message-ID: Thanks Martin! We are trying to do what you suggested, however I need a way to easily identify a JavaEE component? I don't want to go through all classes to process them. I need to filter out non-JavaEE component classes as you have handled them. The one solution I can think of is to build a static list but it is very urgly. The following EE7 spec has made EE component classes very similar to CDI beans: Per the CDI specification, dependency injection is supported on managed beans. There are currently three ways for a class to become a managed bean: 1.Being an EJB session bean component. 2.Being annotated with the ManagedBean annotation. 3.Satisfying the conditions described in the CDI specification. Classes that satisfy at least one of these conditions will be eligible for full dependency injection support as described in the CDI specification. Component classes listed in Table EE.5-1 that satisfy the third condition above, but neither the first nor the second condition, can also be used as CDI managed beans if they are annotated with a CDI bean-defining annotation or contained in a bean archive for which CDI is enabled. However, if they are used as CDI managed beans (e.g., injected into other managed classes), the instances that are managed by CDI may not be the instances that are managed by the Java EE container. Thanks Emily On Mon, May 18, 2015 at 12:38 PM, Martin Kouba wrote: > I think you should create an InjectionTarget upfront, during EE component > initialization (i.e. cache the IT for a component, > similarly to how javax.enterprise.inject.spi.Unmanaged works) and before > an EE component instance is instantiated. > > Martin > > Dne 18.5.2015 v 11:38 Emily Jiang napsal(a): > >> Thank you Martin! I did an experiment with your suggestion. The >> >> org.jboss.weld.manager.api.WeldManager.createInjectionTargetBuilder(AnnotatedType) >> for EE components was called by us when an EE component class is >> instanciated so it is too late for the validation (I think this api is >> used for creating instances or I was wrong, please explain a bit more). >> The validation has to happen during weld WeldBootstrap.validateBeans(), >> so an DefinitionException should cause the deployment failure. >> >> On Mon, May 18, 2015 at 9:02 AM, Martin Kouba > > wrote: >> >> Emily, >> >> I've looked at WildFly integration code and it makes use of >> >> org.jboss.weld.manager.api.WeldManager.createInjectionTargetBuilder(AnnotatedType) >> for EE components, i.e. delegates validation to weld implemetation. >> >> M >> >> Dne 18.5.2015 v 09:51 Emily Jiang napsal(a): >> >> oops. yes. Can you shed some lights on this problem? >> >> On Mon, May 18, 2015 at 8:48 AM, Martin Kouba > >> >> wrote: >> >> Emily, >> >> I believe this one belongs rather to the weld-dev ML. >> >> Martin >> >> Dne 18.5.2015 v 09:23 Emily Jiang napsal(a): >> >> >> In CDI1.2 spec, section 5.5.7 >> If a Java EE component class supporting injection that >> is not a >> bean has >> an injection point of >> type InjectionPoint and qualifier @Default, the container >> automatically >> detects the problem >> and treats it as a definition error. >> >> How can I plugin this validation? Is there a callback >> spi I can >> use to >> validate the injection point on JavaEE component? This >> exception >> needs >> to be thrown during the application deployment. >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> > >> >> >> >> >> >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> > >> >> >> -- >> Martin Kouba >> Software Engineer >> Red Hat, Czech Republic >> >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150527/9b5f34bd/attachment.html From emijiang6 at googlemail.com Wed May 27 10:24:26 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Wed, 27 May 2015 15:24:26 +0100 Subject: [weld-dev] Unable to find java.lang.Integer in any bean archives In-Reply-To: <5562F495.70005@redhat.com> References: <5562B912.8010605@redhat.com> <5562F495.70005@redhat.com> Message-ID: Thanks Jozef! I agree with you that it is best to create bda according to classloading and wire the graph according to classloading hierarchy. On Mon, May 25, 2015 at 11:08 AM, Jozef Hartinger wrote: > > On 05/25/2015 11:07 AM, Emily Jiang wrote: > > Thank you Jozef! I also figured this out after I debugged the case > further and reread the javadoc. Would you recommend to create one bda for > every given class (not app class) or we should design a special archive to > hold all this kind of classes or it does not matter much? > > You'll need to honor accessibility in these archives. Therefore, for > example Integer and Long can share a single bean archive but e.g. a > different class that is not accessible from Integer and Long needs to be > put in a separate bean archive and accessibility of the classes needs to be > reflected in the BDA graph. > > One option we use in WildFly for these additional bean archives is to have > a bean archive per classloader. > > > As for adding the bda to the graph, from my understanding, these classes > should be visible to every other classes in the deployment. Therefore, this > new bda should be accessible to all other bdas in this deployment, right? > > Yes, it is true for this particular class. If however > loadBeanDeploymentArchive() was called for a different class (e.g. for a > class from a web archive's library jar that is not itself a bean archive) > then, as such class is not necessarily accessible from every bean archive, > neither should be the returned bean archive. > > Thanks > Emily > > On Mon, May 25, 2015 at 6:54 AM, Jozef Hartinger > wrote: > >> Emily, >> >> see the JavaDoc here: >> http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/bootstrap/spi/Deployment.html#loadBeanDeploymentArchive-java.lang.Class >> - >> >> Specifically, it says: >> >> " If the deployment archive containing the given class is not currently >> a bean deployment archive, it must be added to the bean deployment archive >> graph and returned." >> >> Therefore, even though the given class is not part of an existing bean >> archive, it should be handled by the integrator, added to the bean archive >> graph and returned from the method. >> >> HTH, >> >> Jozef >> >> >> On 05/24/2015 09:58 AM, Emily Jiang wrote: >> >> I'm trying to run the cdi tck but got an error for the following test: >> In the test: >> org.jboss.cdi.tck.tests.definition.bean.custom.CustomBeanImplementationTest >> Method: arquillianBeforeClass >> >> >> >> Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-000817: >> Unable to find Bean Deployment Archive for class java.lang.Integer >> at >> org.jboss.weld.util.DeploymentStructures.getOrCreateBeanDeployment(DeploymentStructures.java:39) >> at >> org.jboss.weld.bootstrap.events.AbstractBeanDiscoveryEvent.getOrCreateBeanDeployment(AbstractBeanDiscoveryEvent.java:70) >> at >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.processBean(AfterBeanDiscoveryImpl.java:86) >> at >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:186) >> ... 15 more >> >> It seems that Custom bean was added by an extension but the bean >> implements Bean. Surely the java.lang.Interger should not be any >> bean archives. Can someone tell me what I might done wrong? Will integrator >> need to do something to cater for all of the java.x classes or Weld should >> handle this? >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> >> _______________________________________________ >> weld-dev mailing listweld-dev at lists.jboss.orghttps://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/20150527/4632f02e/attachment-0001.html From emijiang6 at googlemail.com Thu May 28 05:42:30 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Thu, 28 May 2015 10:42:30 +0100 Subject: [weld-dev] JavaEE component class vs. Weld managed classes Message-ID: I need to fire events for each JavaEE component class (e.g. process injectionTarget, injectionPoint etc) during Weld bootstrap phase. At the moment, I am think to go through all bdas per deployment and process all classes in the bda and fire events for each JavaEE component classes as Weld leaves it to be handled by the integrator. What is the best way to find out which class is JavaEE component class? I don't like to idea of building a long hardcoded list from the EE.5-1 table of the JavaEE7 spec. -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150528/2d7e4938/attachment.html From jharting at redhat.com Fri May 29 02:30:10 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Fri, 29 May 2015 08:30:10 +0200 Subject: [weld-dev] JavaEE component class vs. Weld managed classes In-Reply-To: References: Message-ID: <55680772.6030205@redhat.com> I suppose you already must have code capable of identifying those components - i.e. the Servlet container must be able to discover Servlets in a web application. Therefore, the best way probably is to hook into these "Java EE component supporting" pieces of code instead of discovering the EE components yourself in the CDI integration code. We do exactly this in WildFly where we let the other subsystems identify EE components and then override the factories for these components to actually use InjectionTargets (and fire PIT, PIP in the process). HTH, Jozef On 05/28/2015 11:42 AM, Emily Jiang wrote: > I need to fire events for each JavaEE component class (e.g. process > injectionTarget, injectionPoint etc) during Weld bootstrap phase. At > the moment, I am think to go through all bdas per deployment and > process all classes in the bda and fire events for each JavaEE > component classes as Weld leaves it to be handled by the integrator. > What is the best way to find out which class is JavaEE component > class? I don't like to idea of building a long hardcoded list from the > EE.5-1 table of the JavaEE7 spec. > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150529/e7b2755a/attachment.html From ooo_saturn7 at mail.ru Sat May 30 08:53:07 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Sat, 30 May 2015 15:53:07 +0300 Subject: [weld-dev] =?utf-8?q?CDI+OSGI=3A_bundle_packages_scope?= Message-ID: <1432990387.12789305@f378.i.mail.ru> I use javase and solution osgi (felix)+cdi(weld)+paxcdi. I have two bundles A and B. Bundle B is a lib bundle. In bundle A I have one class and one package. package com.example.firstpackage;import com.example.secondpackage.Class2;publicclassClass1{@InjectprivateClass2 class2;} In bundle B I have two classes and two packages package com.example.secondpackage;import com.example.thirdpackage.Class3;publicclassClass2{@InjectprivateClass3 class3;} and package com.example.thirdpackage;publicclassClass3{....} I install and start both bundles. The problem - pax (or weld) for injecting in classes of bundle A scans only those packages which are imported for classes IN bundle A. In my example - CDI for injecting in Class1 Class2 will scan com.example.secondpackage of bundle B. However, it will throw exception as Class2 needs Class3 but com.example.thirdpackage is not scanned for bundle A (as it's not imported!!!). com.example.thirdpackage is only scanned for bundle B but, as I understand every bundles for cdi has its own scope. How to fix it? -- ????????? ???????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150530/5200ddf9/attachment.html