From manovotn at redhat.com  Tue Apr  3 04:23:42 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Tue, 3 Apr 2018 04:23:42 -0400 (EDT)
Subject: [weld-dev] What is the best way to pass cofiguration to CDI
 bean using Weld?
In-Reply-To: <1522494479.872083739@f159.i.mail.ru>
References: <1522494479.872083739@f159.i.mail.ru>
Message-ID: <1192806847.15546971.1522743822341.JavaMail.zimbra@redhat.com>

Hi Alex,

Not sure if I get what you need to do, but I'll take a shot at it.
What about using @PostConstruct interceptor, in which you take the injected Application bean and use it to set internal state in SomeManagerImpl?
Same could be done directly within constructor (with @Inject annotation) or an initializer method.

E.g.

@ApplicationScoped
public class SomeManagerImpl implements SomeManager{} {

 private MyConfiguration config;

 @Inject
 Application app;

 @PostConstruct
 public void doSomeInit() {
  config = app.getConfig(); // get config from Application and appply here
 }
}

If I misunderstood your question, please correct me :)

Matej


----- Original Message -----
> From: "Alex Sviridov" <ooo_saturn7 at mail.ru>
> To: "weld-dev" <weld-dev at lists.jboss.org>
> Sent: Saturday, March 31, 2018 1:07:59 PM
> Subject: [weld-dev] What is the best way to pass cofiguration to CDI bean using Weld?
> 
> Hi all
> 
> Could anyone suggest solution for the following situation.
> Lets suppose we have:
> 
> public interface SomeManager{}
> 
> @ApplicationScoped
> public class SomeManagerImpl implements SomeManager{}
> 
> @ApplicationScoped
> public class Application {} //application entry point
> 
> In Application I need to pass configuration to SomeManagerImpl, but I don't
> want to
> add setConfiguration method to SomeManager interface. What is the best way
> to do it in Weld? Maybe I use some CDI mechanisms, or add extra classes.
> Please, help.
> 
> Best regards, Alex Sviridov
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev

From struberg at yahoo.de  Wed Apr  4 13:39:52 2018
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 4 Apr 2018 17:39:52 +0000 (UTC)
Subject: [weld-dev] What is the best way to pass cofiguration to CDI
 bean using Weld?
In-Reply-To: <1192806847.15546971.1522743822341.JavaMail.zimbra@redhat.com>
References: <1522494479.872083739@f159.i.mail.ru>
	<1192806847.15546971.1522743822341.JavaMail.zimbra@redhat.com>
Message-ID: <1483186994.1682564.1522863592022@mail.yahoo.com>

you could look at Apache DeltaSpike @Configuration and he whole DS config mechanism.
http://deltaspike.apache.org/documentation/configuration.html
It's battle proven and also the origin of microprofile-config and JSR-382.Runs on anything EE6 ++, from Java7 to Java10
LieGrue,strub
 

    On Tuesday, 3 April 2018, 10:25:38 CEST, Matej Novotny <manovotn at redhat.com> wrote:  
 
 Hi Alex,

Not sure if I get what you need to do, but I'll take a shot at it.
What about using @PostConstruct interceptor, in which you take the injected Application bean and use it to set internal state in SomeManagerImpl?
Same could be done directly within constructor (with @Inject annotation) or an initializer method.

E.g.

@ApplicationScoped
public class SomeManagerImpl implements SomeManager{} {

 private MyConfiguration config;

 @Inject
 Application app;

 @PostConstruct
 public void doSomeInit() {
? config = app.getConfig(); // get config from Application and appply here
 }
}

If I misunderstood your question, please correct me :)

Matej


----- Original Message -----
> From: "Alex Sviridov" <ooo_saturn7 at mail.ru>
> To: "weld-dev" <weld-dev at lists.jboss.org>
> Sent: Saturday, March 31, 2018 1:07:59 PM
> Subject: [weld-dev] What is the best way to pass cofiguration to CDI bean using Weld?
> 
> Hi all
> 
> Could anyone suggest solution for the following situation.
> Lets suppose we have:
> 
> public interface SomeManager{}
> 
> @ApplicationScoped
> public class SomeManagerImpl implements SomeManager{}
> 
> @ApplicationScoped
> public class Application {} //application entry point
> 
> In Application I need to pass configuration to SomeManagerImpl, but I don't
> want to
> add setConfiguration method to SomeManager interface. What is the best way
> to do it in Weld? Maybe I use some CDI mechanisms, or add extra classes.
> Please, help.
> 
> Best regards, Alex Sviridov
> 
> _______________________________________________
> 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
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180404/fc90fedf/attachment.html 

From BENJAMIC at uk.ibm.com  Fri Apr 13 15:33:58 2018
From: BENJAMIC at uk.ibm.com (Benjamin Confino)
Date: Fri, 13 Apr 2018 20:33:58 +0100
Subject: [weld-dev] WIP fix for https://issues.jboss.org/browse/WELD-1130
Message-ID: <OF4AC72C0B.6D6BF83F-ON0025826E.006B6717-8025826E.006B7B02@notes.na.collabserv.com>

Hello

I posed 
https://github.com/benjamin-confino/core/commit/35d055cd9a841cfbdf2bcb2aaa3e0d8d6116ec1c 
to this lift list month but have not heard any feedback. When can I expect 
to hear if this concept is good in principal? If the concept is good I can 
begin investigating how to extend the idea to conversation scopes and 
write a test. 

Regards
Benjamin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180413/527b7235/attachment.html 

From mkouba at redhat.com  Wed Apr 18 08:02:49 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 18 Apr 2018 14:02:49 +0200
Subject: [weld-dev] WIP fix for https://issues.jboss.org/browse/WELD-1130
In-Reply-To: <OF4AC72C0B.6D6BF83F-ON0025826E.006B6717-8025826E.006B7B02@notes.na.collabserv.com>
References: <OF4AC72C0B.6D6BF83F-ON0025826E.006B6717-8025826E.006B7B02@notes.na.collabserv.com>
Message-ID: <c0fda5d4-36a5-fd6a-be76-48a7482a9b30@redhat.com>

Hi Benjamin,

I'm sorry but the Weld team is burried under some high priority issues. 
I've quickly went through your proposal and have few comments.

1. I think it would be more convenient to modify 
org.jboss.weld.module.web.context.beanstore.http.AbstractSessionBeanStore.getAttribute(String) 
which is used for both the HTTP session and the conversation contexts

2. +1 for config property, we probably need a better name though ;-)

3. You're probably aware that this would not solve the problem 
completely. It should trigger the replication when a @SessionScoped bean 
instance is obtained from the context, e.g. when a client proxy method 
is invoked. However, there are some optimizations in Weld which prevent 
the context lookup (see also 
org.jboss.weld.bean.ContextualInstanceStrategy). Also the replication 
may happen before the state is actually changed - it really depends on 
replication impl details. Still, I agree that this would improve the 
usability.

4. +10 for tests. But I guess it would be tricky to write an automated 
test for this.

Martin

Dne 13.4.2018 v 21:33 Benjamin Confino napsal(a):
> Hello
> 
> I posed 
> https://github.com/benjamin-confino/core/commit/35d055cd9a841cfbdf2bcb2aaa3e0d8d6116ec1cto 
> this lift list month but have not heard any feedback. When can I expect 
> to hear if this concept is good in principal? If the concept is good I 
> can begin investigating how to extend the idea to conversation scopes 
> and write a test.
> 
> Regards
> Benjamin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

From mkouba at redhat.com  Wed Apr 18 08:22:53 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 18 Apr 2018 14:22:53 +0200
Subject: [weld-dev] WIP fix for https://issues.jboss.org/browse/WELD-1130
In-Reply-To: <c0fda5d4-36a5-fd6a-be76-48a7482a9b30@redhat.com>
References: <OF4AC72C0B.6D6BF83F-ON0025826E.006B6717-8025826E.006B7B02@notes.na.collabserv.com>
	<c0fda5d4-36a5-fd6a-be76-48a7482a9b30@redhat.com>
Message-ID: <e26e4ef2-a48b-ee5e-9ed4-59d92c089063@redhat.com>

Dne 18.4.2018 v 14:02 Martin Kouba napsal(a):
> Hi Benjamin,
> 
> I'm sorry but the Weld team is burried under some high priority issues. 
> I've quickly went through your proposal and have few comments.
> 
> 1. I think it would be more convenient to modify 
> org.jboss.weld.module.web.context.beanstore.http.AbstractSessionBeanStore.getAttribute(String) 

Sorry, I meant 
org.jboss.weld.module.web.context.beanstore.http.AbstractSessionBeanStore.get(BeanIdentifier)

> which is used for both the HTTP session and the conversation contexts
> 
> 2. +1 for config property, we probably need a better name though ;-)
> 
> 3. You're probably aware that this would not solve the problem 
> completely. It should trigger the replication when a @SessionScoped bean 
> instance is obtained from the context, e.g. when a client proxy method 
> is invoked. However, there are some optimizations in Weld which prevent 
> the context lookup (see also 
> org.jboss.weld.bean.ContextualInstanceStrategy). Also the replication 
> may happen before the state is actually changed - it really depends on 
> replication impl details. Still, I agree that this would improve the 
> usability.
> 
> 4. +10 for tests. But I guess it would be tricky to write an automated 
> test for this.
> 
> Martin
> 
> Dne 13.4.2018 v 21:33 Benjamin Confino napsal(a):
>> Hello
>>
>> I posed 
>> https://github.com/benjamin-confino/core/commit/35d055cd9a841cfbdf2bcb2aaa3e0d8d6116ec1cto 
>> this lift list month but have not heard any feedback. When can I 
>> expect to hear if this concept is good in principal? If the concept is 
>> good I can begin investigating how to extend the idea to conversation 
>> scopes and write a test.
>>
>> Regards
>> Benjamin
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with 
>> number 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
>> 3AU
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From BENJAMIC at uk.ibm.com  Wed Apr 18 12:33:15 2018
From: BENJAMIC at uk.ibm.com (Benjamin Confino)
Date: Wed, 18 Apr 2018 17:33:15 +0100
Subject: [weld-dev] WIP fix for https://issues.jboss.org/browse/WELD-1130
In-Reply-To: <c0fda5d4-36a5-fd6a-be76-48a7482a9b30@redhat.com>
References: <OF4AC72C0B.6D6BF83F-ON0025826E.006B6717-8025826E.006B7B02@notes.na.collabserv.com>
	<c0fda5d4-36a5-fd6a-be76-48a7482a9b30@redhat.com>
Message-ID: <OFFBFA3A6E.F0AC0905-ON00258273.00594D0F-80258273.005AEF74@notes.na.collabserv.com>

Hello Martin. 

Thank you for the feedback. 

Moving the change to AbstractSessionBeanStore.get(BeanIdentifier) sounds 
like a good idea, and I am happy to change the config property name to 
anything you would like. What did you have in mind? 

In regards to point 2, I believe my customer's configuration will afford 
us some leeway. Providing that the caching still allows a call to get() 
once every two minuets I think we will not have a problem. As always 
though, the proof will be testing it, I was able to get the customer's 
test application working with the WIP fix I wrote so hopefully their live 
application will work too. 

If you can think of any strategy for writing an automated test let me 
know. Apart from that I expect I will have new commits based on your 
suggestion soom. 

Regards
Benjamin





From:   Martin Kouba <mkouba at redhat.com>
To:     Benjamin Confino <BENJAMIC at uk.ibm.com>, weld-dev at lists.jboss.org
Date:   18/04/2018 13:04
Subject:        Re: [weld-dev] WIP fix for 
https://issues.jboss.org/browse/WELD-1130



Hi Benjamin,

I'm sorry but the Weld team is burried under some high priority issues. 
I've quickly went through your proposal and have few comments.

1. I think it would be more convenient to modify 
org.jboss.weld.module.web.context.beanstore.http.AbstractSessionBeanStore.getAttribute(String) 

which is used for both the HTTP session and the conversation contexts

2. +1 for config property, we probably need a better name though ;-)

3. You're probably aware that this would not solve the problem 
completely. It should trigger the replication when a @SessionScoped bean 
instance is obtained from the context, e.g. when a client proxy method 
is invoked. However, there are some optimizations in Weld which prevent 
the context lookup (see also 
org.jboss.weld.bean.ContextualInstanceStrategy). Also the replication 
may happen before the state is actually changed - it really depends on 
replication impl details. Still, I agree that this would improve the 
usability.

4. +10 for tests. But I guess it would be tricky to write an automated 
test for this.

Martin

Dne 13.4.2018 v 21:33 Benjamin Confino napsal(a):
> Hello
> 
> I posed 
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_benjamin-2Dconfino_core_commit_35d055cd9a841cfbdf2bcb2aaa3e0d8d6116ec1cto&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=h44psnUUWe961Di4IEKfnHhsSfRzXKxVIpAMgp2r0LI&s=v_EHx3focK723Wv9TX7fVy4pYYq7or0XSJVFhVrezPo&e= 

> this lift list month but have not heard any feedback. When can I expect 
> to hear if this concept is good in principal? If the concept is good I 
> can begin investigating how to extend the idea to conversation scopes 
> and write a test.
> 
> Regards
> Benjamin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 

> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_weld-2Ddev&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=h44psnUUWe961Di4IEKfnHhsSfRzXKxVIpAMgp2r0LI&s=zmOPLMTgosB3_X_zWg_rgSt6EgDlEZTmkAKbg6eRs-o&e=

> 




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180418/de0c4031/attachment.html 

From BENJAMIC at uk.ibm.com  Thu Apr 19 08:36:43 2018
From: BENJAMIC at uk.ibm.com (Benjamin Confino)
Date: Thu, 19 Apr 2018 13:36:43 +0100
Subject: [weld-dev] WIP fix for https://issues.jboss.org/browse/WELD-1130
In-Reply-To: <e26e4ef2-a48b-ee5e-9ed4-59d92c089063@redhat.com>
References: <OF4AC72C0B.6D6BF83F-ON0025826E.006B6717-8025826E.006B7B02@notes.na.collabserv.com>
	<c0fda5d4-36a5-fd6a-be76-48a7482a9b30@redhat.com>
	<e26e4ef2-a48b-ee5e-9ed4-59d92c089063@redhat.com>
Message-ID: <OFFD3C674D.9FE7A52A-ON00258274.0045336F-80258274.0045479B@notes.na.collabserv.com>

Hello

Pull requests for the updated patch are up :) If anyone has a better name 
for the property please let me know. 

Regards
Benjamin



From:   Martin Kouba <mkouba at redhat.com>
To:     Benjamin Confino <BENJAMIC at uk.ibm.com>, weld-dev at lists.jboss.org
Date:   18/04/2018 13:22
Subject:        Re: [weld-dev] WIP fix for 
https://issues.jboss.org/browse/WELD-1130



Dne 18.4.2018 v 14:02 Martin Kouba napsal(a):
> Hi Benjamin,
> 
> I'm sorry but the Weld team is burried under some high priority issues. 
> I've quickly went through your proposal and have few comments.
> 
> 1. I think it would be more convenient to modify 
> 
org.jboss.weld.module.web.context.beanstore.http.AbstractSessionBeanStore.getAttribute(String) 


Sorry, I meant 
org.jboss.weld.module.web.context.beanstore.http.AbstractSessionBeanStore.get(BeanIdentifier)

> which is used for both the HTTP session and the conversation contexts
> 
> 2. +1 for config property, we probably need a better name though ;-)
> 
> 3. You're probably aware that this would not solve the problem 
> completely. It should trigger the replication when a @SessionScoped bean 

> instance is obtained from the context, e.g. when a client proxy method 
> is invoked. However, there are some optimizations in Weld which prevent 
> the context lookup (see also 
> org.jboss.weld.bean.ContextualInstanceStrategy). Also the replication 
> may happen before the state is actually changed - it really depends on 
> replication impl details. Still, I agree that this would improve the 
> usability.
> 
> 4. +10 for tests. But I guess it would be tricky to write an automated 
> test for this.
> 
> Martin
> 
> Dne 13.4.2018 v 21:33 Benjamin Confino napsal(a):
>> Hello
>>
>> I posed 
>> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_benjamin-2Dconfino_core_commit_35d055cd9a841cfbdf2bcb2aaa3e0d8d6116ec1cto&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=-ZUKVCrQQ5XNALx_gpYc6uHtIB2aBo3vfdvhPFMyGq4&s=8MGYr6cF9UfBNJIHJLA4qMWaJNF5zfqmbTsMLN6LMjY&e= 

>> this lift list month but have not heard any feedback. When can I 
>> expect to hear if this concept is good in principal? If the concept is 
>> good I can begin investigating how to extend the idea to conversation 
>> scopes and write a test.
>>
>> Regards
>> Benjamin
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with 
>> number 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
>> 3AU
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_weld-2Ddev&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=-ZUKVCrQQ5XNALx_gpYc6uHtIB2aBo3vfdvhPFMyGq4&s=V5hOUdwYU955kSnYhICFsY4JC-dIfRT_9wxy9_cAsVo&e=

>>

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180419/c1acff5d/attachment.html 

From manovotn at redhat.com  Thu Apr 26 11:06:09 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Thu, 26 Apr 2018 11:06:09 -0400 (EDT)
Subject: [weld-dev] Weld 3.0.4.Final + Weld API 3.0.SP3
In-Reply-To: <1754900169.22953896.1524753310052.JavaMail.zimbra@redhat.com>
Message-ID: <400522131.22971049.1524755169002.JavaMail.zimbra@redhat.com>

Weld 3.0.4.Final is out and so is Weld API 3.0.SP3 which goes along with it.
See also release announcement - http://weld.cdi-spec.org/news/2018/04/26/weld-304Final/

Matej

From gordon.hutchison at gmail.com  Thu Apr 26 11:10:32 2018
From: gordon.hutchison at gmail.com (Gordon Hutchison)
Date: Thu, 26 Apr 2018 16:10:32 +0100
Subject: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest
 failure - ShouldThrow...Definition or Deployment Exception? - spec
 inconsistency??
Message-ID: <CAHeHssWM0jV7h8U=cEK0po9yQfEKVTRg=Hx5cM_65n39NA0fCg@mail.gmail.com>

Hi Folks,

I work in the IBM CDI implementation team.

We are running the CDI 2.0 TCK/CDS and get a test failure on:

org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.
ObserverMethodWithoutNotifyMethodTest

that I need some advice on.

The test has:

import javax.enterprise.inject.spi.DeploymentException;

    @ShouldThrowException(DeploymentException.class)


    // unable to process ObserverMethodConfigurator due to missing notify
method impl
    @Test
    @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id =
"ee") })
    public void unableToProcessObserverMethodConfigurator() {
    }

This behaviour is specified in
   https://docs.jboss.org/cdi/spec/2.0/cdi-spec-with-
assertions.html#after_bean_discovery
(search for "ee)" )

ee) If the container is unable to process the ObserverMethodConfigurator it
automatically detects the problem and treats it as a deployment problem.
ObserverMethodWithoutNotifyMethodTest.unableToProcessObserverMethodC
onfigurator()


However what we see coming back from Weld is not a javax
DeploymentException but a javax DefinitionException wrapping a weld
DeploymentException cause

Stack Dump = javax.enterprise.inject.spi.DefinitionException:
org.jboss.weld.exceptions.DeploymentException: WELD-000179:
ObserverMethodConfigurator created by org.jboss.cdi.tck.tests.
extensions.lifecycle.broken.observerMethod.AfterBeanDiscoveryObserver at d31423c
cannot be processed
        at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.
finish(AfterBeanDiscoveryImpl.java:180)
<<<<<<< Problem????
        at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.
fire(AfterBeanDiscoveryImpl.java:76)
        at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:446)

        at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)

        at com.ibm.ws.cdi.impl.CDIContainerImpl.startInitialization(CDIContainerImpl.java:149)

        at com.ibm.ws.cdi.liberty.CDIRuntimeImpl.applicationStarting(CDIRuntimeImpl.java:400)

        at com.ibm.ws.container.service.state.internal.
ApplicationStateManager.fireStarting(ApplicationStateManager.java:28)
        at com.ibm.ws.container.service.state.internal.
StateChangeServiceImpl.fireApplicationStarting(StateChangeServiceImpl.java:50)

        at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.
preDeployApp(DeployedAppInfoBase.java:383)
        at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.
deployApp(DeployedAppInfoBase.java:412)
        at com.ibm.ws.app.manager.war.internal.WARApplicationHandlerImpl.
install(WARApplicationHandlerImpl.java:65)
        at com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:140)

        at com.ibm.ws.app.manager.internal.statemachine.
ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.java:1258)

        at com.ibm.ws.app.manager.internal.statemachine.
ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:873)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

        at java.lang.Thread.run(Thread.java:748)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-000179:
ObserverMethodConfigurator created by org.jboss.cdi.tck.tests.
extensions.lifecycle.broken.observerMethod.AfterBeanDiscoveryObserver at d31423c
cannot be processed
        at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$
ObserverRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:368)
        at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.
processObserverRegistration(AfterBeanDiscoveryImpl.java:268)
        at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.
finish(AfterBeanDiscoveryImpl.java:177)
        ... 16 more
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000415:
Custom implementation of observer method does not override either notify(T)
or notify(EventContext<T>): org.jboss.weld.bootstrap.events.configurator.
ObserverMethodConfiguratorImpl at 7e164c01
        at org.jboss.weld.bootstrap.events.configurator.
ObserverMethodConfiguratorImpl$ImmutableObserverMethod.<init>(
ObserverMethodConfiguratorImpl.java:272)
        at org.jboss.weld.bootstrap.events.configurator.
ObserverMethodConfiguratorImpl.complete(ObserverMethodConfiguratorImpl.java:234)

        at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$
ObserverRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:366)
        ... 18 more


We can see the AfterBeanDiscoveryImpl.java:180 being

    /**
     * Bean and observer registration is delayed until after all {@link
AfterBeanDiscovery} observers are notified.
     */
    private void finish() {
        try {
            GlobalEnablementBuilder globalEnablementBuilder =
getBeanManager().getServices().get(GlobalEnablementBuilder.class);
            for (BeanRegistration registration : additionalBeans) {
                processBeanRegistration(registration,
globalEnablementBuilder);
            }
            for (ObserverRegistration registration : additionalObservers) {
                processObserverRegistration(registration);
            }
        } catch (Exception e) {
            throw new DefinitionException(e);     <<<<<<  line 180
        }
    }


I am also aware of, in http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf
11.5.3.,
    "If any observer method of the AfterBeanDiscovery event throws an
exception, the exception is treated as a definition error by the container"

So why is the test expecting DeploymentException

import javax.enterprise.inject.spi.DeploymentException;
...      @ShouldThrowException(DeploymentException.class)


It seems like the test is seeing
    @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id =
"ee") })
        If the container is unable to process the
ObserverMethodConfigurator it automatically detects the problem and treats
it as a deployment problem.
as dominant but the weld implementation is seeing
       http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf: 11.5.3
       If any observer method of the AfterBeanDiscovery event throws an
exception, the exception is treated as a definition error by the container"
as dominant.

....and the two do not agree.

So the bottom line is the CDI CTS/TCK test
    org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.
ObserverMethodWithoutNotifyMethodTest
fails due to the inconsistency.

Have I missunderstood the spec contradiction or missed some part of Weld
integration needed?

Gordon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180426/acd29afd/attachment-0001.html 

From gordon.hutchison at gmail.com  Thu Apr 26 11:17:55 2018
From: gordon.hutchison at gmail.com (Gordon Hutchison)
Date: Thu, 26 Apr 2018 16:17:55 +0100
Subject: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest
 failure - ShouldThrow...Definition or Deployment Exception? - spec
 inconsistency??
Message-ID: <CAHeHssUZDyakKVn=yskU-jLRsTgwarTMrQ1wu17JK6y043kCzA@mail.gmail.com>

Hi Folks,

I work in the IBM CDI implementation team.

We are running the CDI 2.0 TCK/CDS and get a test failure on:

org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observer
Method.ObserverMethodWithoutNotifyMethodTest

that I need some advice on.

The test has:

import javax.enterprise.inject.spi.DeploymentException;

    @ShouldThrowException(DeploymentException.class)


    // unable to process ObserverMethodConfigurator due to missing notify
method impl
    @Test
    @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id =
"ee") })
    public void unableToProcessObserverMethodConfigurator() {
    }

This behaviour is specified in
   https://docs.jboss.org/cdi/spec/2.0/cdi-spec-with-assertions
.html#after_bean_discovery
(search for "ee)" )

ee) If the container is unable to process the ObserverMethodConfigurator it
automatically detects the problem and treats it as a deployment problem.
ObserverMethodWithoutNotifyMethodTest.unableToProcessObserve
rMethodConfigurator()


However what we see coming back from Weld is not a javax
DeploymentException but a javax DefinitionException wrapping a weld
DeploymentException cause

Stack Dump = javax.enterprise.inject.spi.DefinitionException:
org.jboss.weld.exceptions.DeploymentException: WELD-000179:
ObserverMethodConfigurator created by org.jboss.cdi.tck.tests.extens
ions.lifecycle.broken.observerMethod.AfterBeanDiscoveryObserver at d31423c
cannot be processed
        at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finis
h(AfterBeanDiscoveryImpl.java:180)                                 <<<<<<<
Problem????
        at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(
AfterBeanDiscoveryImpl.java:76)
        at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:446)

        at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)

        at com.ibm.ws.cdi.impl.CDIContainerImpl.startInitialization(CDIContainerImpl.java:149)

        at com.ibm.ws.cdi.liberty.CDIRuntimeImpl.applicationStarting(CDIRuntimeImpl.java:400)

        at com.ibm.ws.container.service.state.internal.ApplicationState
Manager.fireStarting(ApplicationStateManager.java:28)
        at com.ibm.ws.container.service.state.internal.StateChangeServi
ceImpl.fireApplicationStarting(StateChangeServiceImpl.java:50)
        at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.p
reDeployApp(DeployedAppInfoBase.java:383)
        at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.d
eployApp(DeployedAppInfoBase.java:412)
        at com.ibm.ws.app.manager.war.internal.WARApplicationHandlerImp
l.install(WARApplicationHandlerImpl.java:65)
        at com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:140)

        at com.ibm.ws.app.manager.internal.statemachine.ApplicationStat
eMachineImpl.enterState(ApplicationStateMachineImpl.java:1258)
        at com.ibm.ws.app.manager.internal.statemachine.ApplicationStat
eMachineImpl.run(ApplicationStateMachineImpl.java:873)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

        at java.lang.Thread.run(Thread.java:748)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-000179:
ObserverMethodConfigurator created by org.jboss.cdi.tck.tests.extens
ions.lifecycle.broken.observerMethod.AfterBeanDiscoveryObserver at d31423c
cannot be processed
        at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$Obser
verRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:368)
        at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.proce
ssObserverRegistration(AfterBeanDiscoveryImpl.java:268)
        at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finis
h(AfterBeanDiscoveryImpl.java:177)
        ... 16 more
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000415:
Custom implementation of observer method does not override either notify(T)
or notify(EventContext<T>): org.jboss.weld.bootstrap.event
s.configurator.ObserverMethodConfiguratorImpl at 7e164c01
        at org.jboss.weld.bootstrap.events.configurator.ObserverMethodC
onfiguratorImpl$ImmutableObserverMethod.<init>(ObserverMethodConfiguratorImpl.java:272)

        at org.jboss.weld.bootstrap.events.configurator.ObserverMethodC
onfiguratorImpl.complete(ObserverMethodConfiguratorImpl.java:234)
        at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$Obser
verRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:366)
        ... 18 more


We can see the AfterBeanDiscoveryImpl.java:180 being

    /**
     * Bean and observer registration is delayed until after all {@link
AfterBeanDiscovery} observers are notified.
     */
    private void finish() {
        try {
            GlobalEnablementBuilder globalEnablementBuilder =
getBeanManager().getServices().get(GlobalEnablementBuilder.class);
            for (BeanRegistration registration : additionalBeans) {
                processBeanRegistration(registration,
globalEnablementBuilder);
            }
            for (ObserverRegistration registration : additionalObservers) {
                processObserverRegistration(registration);
            }
        } catch (Exception e) {
            throw new DefinitionException(e);     <<<<<<  line 180
        }
    }


I am also aware of, in http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf
11.5.3.,
    "If any observer method of the AfterBeanDiscovery event throws an
exception, the exception is treated as a definition error by the container"

So why is the test expecting DeploymentException

import javax.enterprise.inject.spi.DeploymentException;
...      @ShouldThrowException(DeploymentException.class)


It seems like the test is seeing
    @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id =
"ee") })
        If the container is unable to process the
ObserverMethodConfigurator it automatically detects the problem and treats
it as a deployment problem.
as dominant but the weld implementation is seeing
       http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf: 11.5.3
       If any observer method of the AfterBeanDiscovery event throws an
exception, the exception is treated as a definition error by the container"
as dominant.

....and the two do not agree.

So the bottom line is the CDI CTS/TCK test
    org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observer
Method.ObserverMethodWithoutNotifyMethodTest
fails due to the inconsistency.

Have I missunderstood the spec contradiction or missed some part of Weld
integration needed?

Gordon Hutchison
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180426/ad013082/attachment.html 

From manovotn at redhat.com  Fri Apr 27 02:26:43 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Fri, 27 Apr 2018 02:26:43 -0400 (EDT)
Subject: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest
 failure - ShouldThrow...Definition or Deployment Exception? - spec
 inconsistency??
In-Reply-To: <CAHeHssUZDyakKVn=yskU-jLRsTgwarTMrQ1wu17JK6y043kCzA@mail.gmail.com>
References: <CAHeHssUZDyakKVn=yskU-jLRsTgwarTMrQ1wu17JK6y043kCzA@mail.gmail.com>
Message-ID: <569483544.23241333.1524810403528.JavaMail.zimbra@redhat.com>

Hi Gordon,

running the test on WFLY (or actually without EE container) gives me the same stacktrace, however the test passes for me.
What is it you fail on exactly?

Debugging a bit shows that @ShouldThrowException annotation (which is guarding the exception in the test) goes through a whole chain of exceptions - having it wrapped should still pass the test.
E.g. it looks at the cause, see if that's assignable, and if it isn't then the method is recursively invoked for Exception.getCause().
Here is a link to Arq. code doing that - https://github.com/arquillian/arquillian-core/blob/master/container/impl-base/src/main/java/org/jboss/arquillian/container/impl/client/container/DeploymentExceptionHandler.java#L63-L66

As for spec point of view...
Wrapping those exceptions meets both criteria mentioned in spec as long as you can get to both of them.
Also, having DefinitionException on top makes sense from user point of view (at least in my opinion) because is it ultimately developer's mistake that he/she did not add the notify() method.
And that subsequently leads to DeploymentException.
Does it make sense?

I'd like to help more but I am not sure whether you are battling some actual test failure or the somewhat clashing sentences in spec itself?

Matej

----- Original Message -----
> From: "Gordon Hutchison" <gordon.hutchison at gmail.com>
> To: weld-dev at lists.jboss.org
> Sent: Thursday, April 26, 2018 5:17:55 PM
> Subject: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest failure - ShouldThrow...Definition or
> Deployment Exception? - spec inconsistency??
> 
> Hi Folks,
> 
> I work in the IBM CDI implementation team.
> 
> We are running the CDI 2.0 TCK/CDS and get a test failure on:
> 
> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.ObserverMethodWithoutNotifyMethodTest
> 
> that I need some advice on.
> 
> The test has:
> 
> import javax.enterprise.inject.spi.De ploymentException;
> 
> @ShouldThrowException(DeploymentException.class)
> 
> 
> // unable to process ObserverMethodConfigurator due to missing notify method
> impl
> @Test
> @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id = "ee")
> })
> public void unableToProcessObserverMethodConfigurator() {
> }
> 
> This behaviour is specified in
> https://docs.jboss.org/cdi/spec/2.0/cdi-spec-with-assertions.html#after_bean_discovery
> (search for "ee)" )
> 
> ee) If the container is unable to process the ObserverMethodConfigurator it
> automatically detects the problem and treats it as a deployment problem.
> ObserverMethodWithoutNotifyMethodTest.unableToProcessObserverMethodConfigurator()
> 
> 
> However what we see coming back from Weld is not a javax DeploymentException
> but a javax DefinitionException wrapping a weld DeploymentException cause
> 
> Stack Dump = javax.enterprise.inject.spi.De finitionException:
> org.jboss.weld.exceptions.DeploymentException: WELD-000179:
> ObserverMethodConfigurator created by
> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.AfterBeanDiscoveryObserver at d31423c
> cannot be processed
> at
> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:180)
> <<<<<<< Problem????
> at
> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:76)
> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:446)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)
> at
> com.ibm.ws.cdi.impl.CDIContainerImpl.startInitialization(CDIContainerImpl.java:149)
> at
> com.ibm.ws.cdi.liberty.CDIRuntimeImpl.applicationStarting(CDIRuntimeImpl.java:400)
> at
> com.ibm.ws.container.service.state.internal.ApplicationStateManager.fireStarting(ApplicationStateManager.java:28)
> at
> com.ibm.ws.container.service.state.internal.StateChangeServiceImpl.fireApplicationStarting(StateChangeServiceImpl.java:50)
> at
> com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.preDeployApp(DeployedAppInfoBase.java:383)
> at
> com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployApp(DeployedAppInfoBase.java:412)
> at com.ibm.ws.app.manager.war.int
> ernal.WARApplicationHandlerImpl.install(WARApplicationHandlerImpl.java:65)
> at
> com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:140)
> at
> com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.java:1258)
> at
> com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:873)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-000179:
> ObserverMethodConfigurator created by
> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.AfterBeanDiscoveryObserver at d31423c
> cannot be processed
> at
> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$ObserverRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:368)
> at
> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.processObserverRegistration(AfterBeanDiscoveryImpl.java:268)
> at
> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:177)
> ... 16 more
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000415: Custom
> implementation of observer method does not override either notify(T) or
> notify(EventContext<T>):
> org.jboss.weld.bootstrap.events.configurator.ObserverMethodConfiguratorImpl at 7e164c01
> at
> org.jboss.weld.bootstrap.events.configurator.ObserverMethodConfiguratorImpl$ImmutableObserverMethod.<init>(ObserverMethodConfiguratorImpl.java:272)
> at
> org.jboss.weld.bootstrap.events.configurator.ObserverMethodConfiguratorImpl.complete(ObserverMethodConfiguratorImpl.java:234)
> at
> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$ObserverRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:366)
> ... 18 more
> 
> 
> We can see the AfterBeanDiscoveryImpl.java:180 being
> 
> /**
> * Bean and observer registration is delayed until after all {@link
> AfterBeanDiscovery} observers are notified.
> */
> private void finish() {
> try {
> GlobalEnablementBuilder globalEnablementBuilder =
> getBeanManager().getServices().get(GlobalEnablementBuilder.class);
> for (BeanRegistration registration : additionalBeans) {
> processBeanRegistration(registration, globalEnablementBuilder);
> }
> for (ObserverRegistration registration : additionalObservers) {
> processObserverRegistration(registration);
> }
> } catch (Exception e) {
> throw new DefinitionException(e); <<<<<< line 180
> }
> }
> 
> 
> I am also aware of, in http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf
> 11.5.3.,
> "If any observer method of the AfterBeanDiscovery event throws an exception,
> the exception is treated as a definition error by the container"
> 
> So why is the test expecting DeploymentException
> 
> import javax.enterprise.inject.spi.De ploymentException;
> ... @ShouldThrowException(DeploymentException.class)
> 
> 
> It seems like the test is seeing
> @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id = "ee")
> })
> If the container is unable to process the ObserverMethodConfigurator it
> automatically detects the problem and treats it as a deployment problem.
> as dominant but the weld implementation is seeing
> http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf : 11.5.3
> If any observer method of the AfterBeanDiscovery event throws an exception,
> the exception is treated as a definition error by the container"
> as dominant.
> 
> ....and the two do not agree.
> 
> So the bottom line is the CDI CTS/TCK test
> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.ObserverMethodWithoutNotifyMethodTest
> fails due to the inconsistency.
> 
> Have I missunderstood the spec contradiction or missed some part of Weld
> integration needed?
> 
> Gordon Hutchison
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev

From mkouba at redhat.com  Fri Apr 27 02:41:45 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Fri, 27 Apr 2018 08:41:45 +0200
Subject: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest
 failure - ShouldThrow...Definition or Deployment Exception? - spec
 inconsistency??
In-Reply-To: <569483544.23241333.1524810403528.JavaMail.zimbra@redhat.com>
References: <CAHeHssUZDyakKVn=yskU-jLRsTgwarTMrQ1wu17JK6y043kCzA@mail.gmail.com>
	<569483544.23241333.1524810403528.JavaMail.zimbra@redhat.com>
Message-ID: <2ff65e87-ef0e-9bb5-da05-e7333e7ffb83@redhat.com>

Dne 27.4.2018 v 08:26 Matej Novotny napsal(a):
> Hi Gordon,
> 
> running the test on WFLY (or actually without EE container) gives me the same stacktrace, however the test passes for me.
> What is it you fail on exactly?
> 
> Debugging a bit shows that @ShouldThrowException annotation (which is guarding the exception in the test) goes through a whole chain of exceptions - having it wrapped should still pass the test.
> E.g. it looks at the cause, see if that's assignable, and if it isn't then the method is recursively invoked for Exception.getCause().
> Here is a link to Arq. code doing that - https://github.com/arquillian/arquillian-core/blob/master/container/impl-base/src/main/java/org/jboss/arquillian/container/impl/client/container/DeploymentExceptionHandler.java#L63-L66


In fact, we're using a customized 
org.jboss.arquillian.container.spi.client.container.DeploymentExceptionTransformer 
for WildFly:
https://github.com/weld/core/blob/master/jboss-tck-runner/src/test/java/org/jboss/weld/tck/wildfly8/WildFly8DeploymentExceptionTransformer.java

> 
> As for spec point of view...
> Wrapping those exceptions meets both criteria mentioned in spec as long as you can get to both of them.
> Also, having DefinitionException on top makes sense from user point of view (at least in my opinion) because is it ultimately developer's mistake that he/she did not add the notify() method.
> And that subsequently leads to DeploymentException.
> Does it make sense?
> 
> I'd like to help more but I am not sure whether you are battling some actual test failure or the somewhat clashing sentences in spec itself?
> 
> Matej
> 
> ----- Original Message -----
>> From: "Gordon Hutchison" <gordon.hutchison at gmail.com>
>> To: weld-dev at lists.jboss.org
>> Sent: Thursday, April 26, 2018 5:17:55 PM
>> Subject: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest failure - ShouldThrow...Definition or
>> Deployment Exception? - spec inconsistency??
>>
>> Hi Folks,
>>
>> I work in the IBM CDI implementation team.
>>
>> We are running the CDI 2.0 TCK/CDS and get a test failure on:
>>
>> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.ObserverMethodWithoutNotifyMethodTest
>>
>> that I need some advice on.
>>
>> The test has:
>>
>> import javax.enterprise.inject.spi.De ploymentException;
>>
>> @ShouldThrowException(DeploymentException.class)
>>
>>
>> // unable to process ObserverMethodConfigurator due to missing notify method
>> impl
>> @Test
>> @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id = "ee")
>> })
>> public void unableToProcessObserverMethodConfigurator() {
>> }
>>
>> This behaviour is specified in
>> https://docs.jboss.org/cdi/spec/2.0/cdi-spec-with-assertions.html#after_bean_discovery
>> (search for "ee)" )
>>
>> ee) If the container is unable to process the ObserverMethodConfigurator it
>> automatically detects the problem and treats it as a deployment problem.
>> ObserverMethodWithoutNotifyMethodTest.unableToProcessObserverMethodConfigurator()
>>
>>
>> However what we see coming back from Weld is not a javax DeploymentException
>> but a javax DefinitionException wrapping a weld DeploymentException cause
>>
>> Stack Dump = javax.enterprise.inject.spi.De finitionException:
>> org.jboss.weld.exceptions.DeploymentException: WELD-000179:
>> ObserverMethodConfigurator created by
>> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.AfterBeanDiscoveryObserver at d31423c
>> cannot be processed
>> at
>> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:180)
>> <<<<<<< Problem????
>> at
>> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:76)
>> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:446)
>> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)
>> at
>> com.ibm.ws.cdi.impl.CDIContainerImpl.startInitialization(CDIContainerImpl.java:149)
>> at
>> com.ibm.ws.cdi.liberty.CDIRuntimeImpl.applicationStarting(CDIRuntimeImpl.java:400)
>> at
>> com.ibm.ws.container.service.state.internal.ApplicationStateManager.fireStarting(ApplicationStateManager.java:28)
>> at
>> com.ibm.ws.container.service.state.internal.StateChangeServiceImpl.fireApplicationStarting(StateChangeServiceImpl.java:50)
>> at
>> com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.preDeployApp(DeployedAppInfoBase.java:383)
>> at
>> com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployApp(DeployedAppInfoBase.java:412)
>> at com.ibm.ws.app.manager.war.int
>> ernal.WARApplicationHandlerImpl.install(WARApplicationHandlerImpl.java:65)
>> at
>> com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:140)
>> at
>> com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.java:1258)
>> at
>> com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:873)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>> at java.lang.Thread.run(Thread.java:748)
>> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-000179:
>> ObserverMethodConfigurator created by
>> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.AfterBeanDiscoveryObserver at d31423c
>> cannot be processed
>> at
>> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$ObserverRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:368)
>> at
>> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.processObserverRegistration(AfterBeanDiscoveryImpl.java:268)
>> at
>> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:177)
>> ... 16 more
>> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000415: Custom
>> implementation of observer method does not override either notify(T) or
>> notify(EventContext<T>):
>> org.jboss.weld.bootstrap.events.configurator.ObserverMethodConfiguratorImpl at 7e164c01
>> at
>> org.jboss.weld.bootstrap.events.configurator.ObserverMethodConfiguratorImpl$ImmutableObserverMethod.<init>(ObserverMethodConfiguratorImpl.java:272)
>> at
>> org.jboss.weld.bootstrap.events.configurator.ObserverMethodConfiguratorImpl.complete(ObserverMethodConfiguratorImpl.java:234)
>> at
>> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$ObserverRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:366)
>> ... 18 more
>>
>>
>> We can see the AfterBeanDiscoveryImpl.java:180 being
>>
>> /**
>> * Bean and observer registration is delayed until after all {@link
>> AfterBeanDiscovery} observers are notified.
>> */
>> private void finish() {
>> try {
>> GlobalEnablementBuilder globalEnablementBuilder =
>> getBeanManager().getServices().get(GlobalEnablementBuilder.class);
>> for (BeanRegistration registration : additionalBeans) {
>> processBeanRegistration(registration, globalEnablementBuilder);
>> }
>> for (ObserverRegistration registration : additionalObservers) {
>> processObserverRegistration(registration);
>> }
>> } catch (Exception e) {
>> throw new DefinitionException(e); <<<<<< line 180
>> }
>> }
>>
>>
>> I am also aware of, in http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf
>> 11.5.3.,
>> "If any observer method of the AfterBeanDiscovery event throws an exception,
>> the exception is treated as a definition error by the container"
>>
>> So why is the test expecting DeploymentException
>>
>> import javax.enterprise.inject.spi.De ploymentException;
>> ... @ShouldThrowException(DeploymentException.class)
>>
>>
>> It seems like the test is seeing
>> @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id = "ee")
>> })
>> If the container is unable to process the ObserverMethodConfigurator it
>> automatically detects the problem and treats it as a deployment problem.
>> as dominant but the weld implementation is seeing
>> http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf : 11.5.3
>> If any observer method of the AfterBeanDiscovery event throws an exception,
>> the exception is treated as a definition error by the container"
>> as dominant.
>>
>> ....and the two do not agree.
>>
>> So the bottom line is the CDI CTS/TCK test
>> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.ObserverMethodWithoutNotifyMethodTest
>> fails due to the inconsistency.
>>
>> Have I missunderstood the spec contradiction or missed some part of Weld
>> integration needed?
>>
>> Gordon Hutchison
>>
>> _______________________________________________
>> 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
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From manovotn at redhat.com  Fri Apr 27 02:54:02 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Fri, 27 Apr 2018 02:54:02 -0400 (EDT)
Subject: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest
 failure - ShouldThrow...Definition or Deployment Exception? - spec
 inconsistency??
In-Reply-To: <2ff65e87-ef0e-9bb5-da05-e7333e7ffb83@redhat.com>
References: <CAHeHssUZDyakKVn=yskU-jLRsTgwarTMrQ1wu17JK6y043kCzA@mail.gmail.com>
	<569483544.23241333.1524810403528.JavaMail.zimbra@redhat.com>
	<2ff65e87-ef0e-9bb5-da05-e7333e7ffb83@redhat.com>
Message-ID: <2064725456.23245905.1524812042220.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Martin Kouba" <mkouba at redhat.com>
> To: "Matej Novotny" <manovotn at redhat.com>, "Gordon Hutchison" <gordon.hutchison at gmail.com>
> Cc: weld-dev at lists.jboss.org
> Sent: Friday, April 27, 2018 8:41:45 AM
> Subject: Re: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest failure - ShouldThrow...Definition or
> Deployment Exception? - spec inconsistency??
> 
> Dne 27.4.2018 v 08:26 Matej Novotny napsal(a):
> > Hi Gordon,
> > 
> > running the test on WFLY (or actually without EE container) gives me the
> > same stacktrace, however the test passes for me.
> > What is it you fail on exactly?
> > 
> > Debugging a bit shows that @ShouldThrowException annotation (which is
> > guarding the exception in the test) goes through a whole chain of
> > exceptions - having it wrapped should still pass the test.
> > E.g. it looks at the cause, see if that's assignable, and if it isn't then
> > the method is recursively invoked for Exception.getCause().
> > Here is a link to Arq. code doing that -
> > https://github.com/arquillian/arquillian-core/blob/master/container/impl-base/src/main/java/org/jboss/arquillian/container/impl/client/container/DeploymentExceptionHandler.java#L63-L66
> 
> 
> In fact, we're using a customized
> org.jboss.arquillian.container.spi.client.container.DeploymentExceptionTransformer
> for WildFly:
> https://github.com/weld/core/blob/master/jboss-tck-runner/src/test/java/org/jboss/weld/tck/wildfly8/WildFly8DeploymentExceptionTransformer.java

Yea, I know.
But this does not take effect outside WildFly where the result is the same.
And even in WFLY it repacks Arquillian-specific exception (org.jboss.arquillian.container.spi.client.container.DeploymentException) into whatever fragment it finds in getCause().

> 
> > 
> > As for spec point of view...
> > Wrapping those exceptions meets both criteria mentioned in spec as long as
> > you can get to both of them.
> > Also, having DefinitionException on top makes sense from user point of view
> > (at least in my opinion) because is it ultimately developer's mistake that
> > he/she did not add the notify() method.
> > And that subsequently leads to DeploymentException.
> > Does it make sense?
> > 
> > I'd like to help more but I am not sure whether you are battling some
> > actual test failure or the somewhat clashing sentences in spec itself?
> > 
> > Matej
> > 
> > ----- Original Message -----
> >> From: "Gordon Hutchison" <gordon.hutchison at gmail.com>
> >> To: weld-dev at lists.jboss.org
> >> Sent: Thursday, April 26, 2018 5:17:55 PM
> >> Subject: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest
> >> failure - ShouldThrow...Definition or
> >> Deployment Exception? - spec inconsistency??
> >>
> >> Hi Folks,
> >>
> >> I work in the IBM CDI implementation team.
> >>
> >> We are running the CDI 2.0 TCK/CDS and get a test failure on:
> >>
> >> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.ObserverMethodWithoutNotifyMethodTest
> >>
> >> that I need some advice on.
> >>
> >> The test has:
> >>
> >> import javax.enterprise.inject.spi.De ploymentException;
> >>
> >> @ShouldThrowException(DeploymentException.class)
> >>
> >>
> >> // unable to process ObserverMethodConfigurator due to missing notify
> >> method
> >> impl
> >> @Test
> >> @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id =
> >> "ee")
> >> })
> >> public void unableToProcessObserverMethodConfigurator() {
> >> }
> >>
> >> This behaviour is specified in
> >> https://docs.jboss.org/cdi/spec/2.0/cdi-spec-with-assertions.html#after_bean_discovery
> >> (search for "ee)" )
> >>
> >> ee) If the container is unable to process the ObserverMethodConfigurator
> >> it
> >> automatically detects the problem and treats it as a deployment problem.
> >> ObserverMethodWithoutNotifyMethodTest.unableToProcessObserverMethodConfigurator()
> >>
> >>
> >> However what we see coming back from Weld is not a javax
> >> DeploymentException
> >> but a javax DefinitionException wrapping a weld DeploymentException cause
> >>
> >> Stack Dump = javax.enterprise.inject.spi.De finitionException:
> >> org.jboss.weld.exceptions.DeploymentException: WELD-000179:
> >> ObserverMethodConfigurator created by
> >> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.AfterBeanDiscoveryObserver at d31423c
> >> cannot be processed
> >> at
> >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:180)
> >> <<<<<<< Problem????
> >> at
> >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:76)
> >> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:446)
> >> at
> >> org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)
> >> at
> >> com.ibm.ws.cdi.impl.CDIContainerImpl.startInitialization(CDIContainerImpl.java:149)
> >> at
> >> com.ibm.ws.cdi.liberty.CDIRuntimeImpl.applicationStarting(CDIRuntimeImpl.java:400)
> >> at
> >> com.ibm.ws.container.service.state.internal.ApplicationStateManager.fireStarting(ApplicationStateManager.java:28)
> >> at
> >> com.ibm.ws.container.service.state.internal.StateChangeServiceImpl.fireApplicationStarting(StateChangeServiceImpl.java:50)
> >> at
> >> com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.preDeployApp(DeployedAppInfoBase.java:383)
> >> at
> >> com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployApp(DeployedAppInfoBase.java:412)
> >> at com.ibm.ws.app.manager.war.int
> >> ernal.WARApplicationHandlerImpl.install(WARApplicationHandlerImpl.java:65)
> >> at
> >> com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:140)
> >> at
> >> com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.java:1258)
> >> at
> >> com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:873)
> >> at
> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> >> at
> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> >> at java.lang.Thread.run(Thread.java:748)
> >> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-000179:
> >> ObserverMethodConfigurator created by
> >> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.AfterBeanDiscoveryObserver at d31423c
> >> cannot be processed
> >> at
> >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$ObserverRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:368)
> >> at
> >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.processObserverRegistration(AfterBeanDiscoveryImpl.java:268)
> >> at
> >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finish(AfterBeanDiscoveryImpl.java:177)
> >> ... 16 more
> >> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000415:
> >> Custom
> >> implementation of observer method does not override either notify(T) or
> >> notify(EventContext<T>):
> >> org.jboss.weld.bootstrap.events.configurator.ObserverMethodConfiguratorImpl at 7e164c01
> >> at
> >> org.jboss.weld.bootstrap.events.configurator.ObserverMethodConfiguratorImpl$ImmutableObserverMethod.<init>(ObserverMethodConfiguratorImpl.java:272)
> >> at
> >> org.jboss.weld.bootstrap.events.configurator.ObserverMethodConfiguratorImpl.complete(ObserverMethodConfiguratorImpl.java:234)
> >> at
> >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$ObserverRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:366)
> >> ... 18 more
> >>
> >>
> >> We can see the AfterBeanDiscoveryImpl.java:180 being
> >>
> >> /**
> >> * Bean and observer registration is delayed until after all {@link
> >> AfterBeanDiscovery} observers are notified.
> >> */
> >> private void finish() {
> >> try {
> >> GlobalEnablementBuilder globalEnablementBuilder =
> >> getBeanManager().getServices().get(GlobalEnablementBuilder.class);
> >> for (BeanRegistration registration : additionalBeans) {
> >> processBeanRegistration(registration, globalEnablementBuilder);
> >> }
> >> for (ObserverRegistration registration : additionalObservers) {
> >> processObserverRegistration(registration);
> >> }
> >> } catch (Exception e) {
> >> throw new DefinitionException(e); <<<<<< line 180
> >> }
> >> }
> >>
> >>
> >> I am also aware of, in http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf
> >> 11.5.3.,
> >> "If any observer method of the AfterBeanDiscovery event throws an
> >> exception,
> >> the exception is treated as a definition error by the container"
> >>
> >> So why is the test expecting DeploymentException
> >>
> >> import javax.enterprise.inject.spi.De ploymentException;
> >> ... @ShouldThrowException(DeploymentException.class)
> >>
> >>
> >> It seems like the test is seeing
> >> @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id =
> >> "ee")
> >> })
> >> If the container is unable to process the ObserverMethodConfigurator it
> >> automatically detects the problem and treats it as a deployment problem.
> >> as dominant but the weld implementation is seeing
> >> http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf : 11.5.3
> >> If any observer method of the AfterBeanDiscovery event throws an
> >> exception,
> >> the exception is treated as a definition error by the container"
> >> as dominant.
> >>
> >> ....and the two do not agree.
> >>
> >> So the bottom line is the CDI CTS/TCK test
> >> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.ObserverMethodWithoutNotifyMethodTest
> >> fails due to the inconsistency.
> >>
> >> Have I missunderstood the spec contradiction or missed some part of Weld
> >> integration needed?
> >>
> >> Gordon Hutchison
> >>
> >> _______________________________________________
> >> 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
> > 
> 
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> 

From gordon.hutchison at gmail.com  Fri Apr 27 05:26:54 2018
From: gordon.hutchison at gmail.com (Gordon Hutchison)
Date: Fri, 27 Apr 2018 10:26:54 +0100
Subject: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest
 failure - ShouldThrow...Definition or Deployment Exception? - spec
 inconsistency??
In-Reply-To: <2064725456.23245905.1524812042220.JavaMail.zimbra@redhat.com>
References: <CAHeHssUZDyakKVn=yskU-jLRsTgwarTMrQ1wu17JK6y043kCzA@mail.gmail.com>
	<569483544.23241333.1524810403528.JavaMail.zimbra@redhat.com>
	<2ff65e87-ef0e-9bb5-da05-e7333e7ffb83@redhat.com>
	<2064725456.23245905.1524812042220.JavaMail.zimbra@redhat.com>
Message-ID: <CAHeHssVx1xGbEV6BF6y2sMCOMY_1n=AqkQAv9Cq_pPLHDPUrHQ@mail.gmail.com>

Thanks for your replies - they are really helpful.

So I think I willl be spending this morning in
https://github.com/OpenLiberty/liberty-arquillian/blob/master/liberty-managed/src/main/java/org/jboss/arquillian/container/was/wlp_managed_8_5/WLPManagedContainer.java
and looking at Liberty FFDC files to build some caused by exception chains
in the Liberty Arquillian Container.

I have to admit I had been through the weld core's ShouldThrow logic.
It was really helpful to understand what the cultural concensus/expectation
for
a TCK @ShouldThrow is, in terms of:

Q1) @ShouldThrows identify one exception but servers usually report a
causal chain -
was it OK for the ShouldThrow exception to be in the causal chain or does
it have to be
the 'top' one. (and what does 'top' mean anyway when the interface is not
code but
a set of messages in a log.)
A1) Clearly it is OK - "It should be thrown" - so it can be a member of a
set
that is thrown - there is no customer Java involved in catching - just log
messages
and these log messages should clearly state, for example
"DefinitionException".

Q2)  In terms of the exact exception thrown was the 'isa' (isAssignable)
test acceptable?
(again this is code but the user interface is log messages)
A2) Clearly everyone uses Arquillian so that impl is the de-facto standard.
However it
is also accepted practice that a Container or for a ExceptionTransformer
might wrap
a, for example WELD DefinitionException with a javax.inject one - it has to
create 100% of the exceptions and usually wraps them up as a cause to an
Arquillian
envelope exception anyway.

Reading the Weld code, I had thought I could get away with no
ExceptionTransformer for now
as long as one of the causal exception chain was assignable from what was
sought (which I think is the case I have).

Thanks so much again - this has made my path ahead clear.

Gordon



On 27 April 2018 at 07:54, Matej Novotny <manovotn at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Martin Kouba" <mkouba at redhat.com>
> > To: "Matej Novotny" <manovotn at redhat.com>, "Gordon Hutchison" <
> gordon.hutchison at gmail.com>
> > Cc: weld-dev at lists.jboss.org
> > Sent: Friday, April 27, 2018 8:41:45 AM
> > Subject: Re: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest
> failure - ShouldThrow...Definition or
> > Deployment Exception? - spec inconsistency??
> >
> > Dne 27.4.2018 v 08:26 Matej Novotny napsal(a):
> > > Hi Gordon,
> > >
> > > running the test on WFLY (or actually without EE container) gives me
> the
> > > same stacktrace, however the test passes for me.
> > > What is it you fail on exactly?
> > >
> > > Debugging a bit shows that @ShouldThrowException annotation (which is
> > > guarding the exception in the test) goes through a whole chain of
> > > exceptions - having it wrapped should still pass the test.
> > > E.g. it looks at the cause, see if that's assignable, and if it isn't
> then
> > > the method is recursively invoked for Exception.getCause().
> > > Here is a link to Arq. code doing that -
> > > https://github.com/arquillian/arquillian-core/blob/master/
> container/impl-base/src/main/java/org/jboss/arquillian/
> container/impl/client/container/DeploymentExceptionHandler.java#L63-L66
> >
> >
> > In fact, we're using a customized
> > org.jboss.arquillian.container.spi.client.container.
> DeploymentExceptionTransformer
> > for WildFly:
> > https://github.com/weld/core/blob/master/jboss-tck-runner/
> src/test/java/org/jboss/weld/tck/wildfly8/WildFly8DeploymentExceptionTra
> nsformer.java
>
> Yea, I know.
> But this does not take effect outside WildFly where the result is the same.
> And even in WFLY it repacks Arquillian-specific exception
> (org.jboss.arquillian.container.spi.client.container.DeploymentException)
> into whatever fragment it finds in getCause().
>
> >
> > >
> > > As for spec point of view...
> > > Wrapping those exceptions meets both criteria mentioned in spec as
> long as
> > > you can get to both of them.
> > > Also, having DefinitionException on top makes sense from user point of
> view
> > > (at least in my opinion) because is it ultimately developer's mistake
> that
> > > he/she did not add the notify() method.
> > > And that subsequently leads to DeploymentException.
> > > Does it make sense?
> > >
> > > I'd like to help more but I am not sure whether you are battling some
> > > actual test failure or the somewhat clashing sentences in spec itself?
> > >
> > > Matej
> > >
> > > ----- Original Message -----
> > >> From: "Gordon Hutchison" <gordon.hutchison at gmail.com>
> > >> To: weld-dev at lists.jboss.org
> > >> Sent: Thursday, April 26, 2018 5:17:55 PM
> > >> Subject: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest
> > >> failure - ShouldThrow...Definition or
> > >> Deployment Exception? - spec inconsistency??
> > >>
> > >> Hi Folks,
> > >>
> > >> I work in the IBM CDI implementation team.
> > >>
> > >> We are running the CDI 2.0 TCK/CDS and get a test failure on:
> > >>
> > >> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.
> ObserverMethodWithoutNotifyMethodTest
> > >>
> > >> that I need some advice on.
> > >>
> > >> The test has:
> > >>
> > >> import javax.enterprise.inject.spi.De ploymentException;
> > >>
> > >> @ShouldThrowException(DeploymentException.class)
> > >>
> > >>
> > >> // unable to process ObserverMethodConfigurator due to missing notify
> > >> method
> > >> impl
> > >> @Test
> > >> @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id =
> > >> "ee")
> > >> })
> > >> public void unableToProcessObserverMethodConfigurator() {
> > >> }
> > >>
> > >> This behaviour is specified in
> > >> https://docs.jboss.org/cdi/spec/2.0/cdi-spec-with-
> assertions.html#after_bean_discovery
> > >> (search for "ee)" )
> > >>
> > >> ee) If the container is unable to process the
> ObserverMethodConfigurator
> > >> it
> > >> automatically detects the problem and treats it as a deployment
> problem.
> > >> ObserverMethodWithoutNotifyMethodTest.unableToProcessObserverMethodC
> onfigurator()
> > >>
> > >>
> > >> However what we see coming back from Weld is not a javax
> > >> DeploymentException
> > >> but a javax DefinitionException wrapping a weld DeploymentException
> cause
> > >>
> > >> Stack Dump = javax.enterprise.inject.spi.De finitionException:
> > >> org.jboss.weld.exceptions.DeploymentException: WELD-000179:
> > >> ObserverMethodConfigurator created by
> > >> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.
> AfterBeanDiscoveryObserver at d31423c
> > >> cannot be processed
> > >> at
> > >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.
> finish(AfterBeanDiscoveryImpl.java:180)
> > >> <<<<<<< Problem????
> > >> at
> > >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.
> fire(AfterBeanDiscoveryImpl.java:76)
> > >> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(
> WeldStartup.java:446)
> > >> at
> > >> org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(
> WeldBootstrap.java:83)
> > >> at
> > >> com.ibm.ws.cdi.impl.CDIContainerImpl.startInitialization(
> CDIContainerImpl.java:149)
> > >> at
> > >> com.ibm.ws.cdi.liberty.CDIRuntimeImpl.applicationStarting(
> CDIRuntimeImpl.java:400)
> > >> at
> > >> com.ibm.ws.container.service.state.internal.ApplicationStateManager.
> fireStarting(ApplicationStateManager.java:28)
> > >> at
> > >> com.ibm.ws.container.service.state.internal.StateChangeServiceImpl.
> fireApplicationStarting(StateChangeServiceImpl.java:50)
> > >> at
> > >> com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.
> preDeployApp(DeployedAppInfoBase.java:383)
> > >> at
> > >> com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.
> deployApp(DeployedAppInfoBase.java:412)
> > >> at com.ibm.ws.app.manager.war.int
> > >> ernal.WARApplicationHandlerImpl.install(WARApplicationHandlerImpl.
> java:65)
> > >> at
> > >> com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(
> StartAction.java:140)
> > >> at
> > >> com.ibm.ws.app.manager.internal.statemachine.
> ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.
> java:1258)
> > >> at
> > >> com.ibm.ws.app.manager.internal.statemachine.
> ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:873)
> > >> at
> > >> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1149)
> > >> at
> > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:624)
> > >> at java.lang.Thread.run(Thread.java:748)
> > >> Caused by: org.jboss.weld.exceptions.DeploymentException:
> WELD-000179:
> > >> ObserverMethodConfigurator created by
> > >> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.
> AfterBeanDiscoveryObserver at d31423c
> > >> cannot be processed
> > >> at
> > >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$
> ObserverRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:368)
> > >> at
> > >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.
> processObserverRegistration(AfterBeanDiscoveryImpl.java:268)
> > >> at
> > >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.
> finish(AfterBeanDiscoveryImpl.java:177)
> > >> ... 16 more
> > >> Caused by: org.jboss.weld.exceptions.DefinitionException:
> WELD-000415:
> > >> Custom
> > >> implementation of observer method does not override either notify(T)
> or
> > >> notify(EventContext<T>):
> > >> org.jboss.weld.bootstrap.events.configurator.
> ObserverMethodConfiguratorImpl at 7e164c01
> > >> at
> > >> org.jboss.weld.bootstrap.events.configurator.
> ObserverMethodConfiguratorImpl$ImmutableObserverMethod.<init>(
> ObserverMethodConfiguratorImpl.java:272)
> > >> at
> > >> org.jboss.weld.bootstrap.events.configurator.
> ObserverMethodConfiguratorImpl.complete(ObserverMethodConfiguratorImpl
> .java:234)
> > >> at
> > >> org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$
> ObserverRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:366)
> > >> ... 18 more
> > >>
> > >>
> > >> We can see the AfterBeanDiscoveryImpl.java:180 being
> > >>
> > >> /**
> > >> * Bean and observer registration is delayed until after all {@link
> > >> AfterBeanDiscovery} observers are notified.
> > >> */
> > >> private void finish() {
> > >> try {
> > >> GlobalEnablementBuilder globalEnablementBuilder =
> > >> getBeanManager().getServices().get(GlobalEnablementBuilder.class);
> > >> for (BeanRegistration registration : additionalBeans) {
> > >> processBeanRegistration(registration, globalEnablementBuilder);
> > >> }
> > >> for (ObserverRegistration registration : additionalObservers) {
> > >> processObserverRegistration(registration);
> > >> }
> > >> } catch (Exception e) {
> > >> throw new DefinitionException(e); <<<<<< line 180
> > >> }
> > >> }
> > >>
> > >>
> > >> I am also aware of, in http://docs.jboss.org/cdi/
> spec/2.0/cdi-spec.pdf
> > >> 11.5.3.,
> > >> "If any observer method of the AfterBeanDiscovery event throws an
> > >> exception,
> > >> the exception is treated as a definition error by the container"
> > >>
> > >> So why is the test expecting DeploymentException
> > >>
> > >> import javax.enterprise.inject.spi.De ploymentException;
> > >> ... @ShouldThrowException(DeploymentException.class)
> > >>
> > >>
> > >> It seems like the test is seeing
> > >> @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id =
> > >> "ee")
> > >> })
> > >> If the container is unable to process the ObserverMethodConfigurator
> it
> > >> automatically detects the problem and treats it as a deployment
> problem.
> > >> as dominant but the weld implementation is seeing
> > >> http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf : 11.5.3
> > >> If any observer method of the AfterBeanDiscovery event throws an
> > >> exception,
> > >> the exception is treated as a definition error by the container"
> > >> as dominant.
> > >>
> > >> ....and the two do not agree.
> > >>
> > >> So the bottom line is the CDI CTS/TCK test
> > >> org.jboss.cdi.tck.tests.extensions.lifecycle.broken.observerMethod.
> ObserverMethodWithoutNotifyMethodTest
> > >> fails due to the inconsistency.
> > >>
> > >> Have I missunderstood the spec contradiction or missed some part of
> Weld
> > >> integration needed?
> > >>
> > >> Gordon Hutchison
> > >>
> > >> _______________________________________________
> > >> 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
> > >
> >
> > --
> > Martin Kouba
> > Senior Software Engineer
> > Red Hat, Czech Republic
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180427/33eff13f/attachment-0001.html