<div dir="ltr"><div><div><div>Thanks for your replies - they are really helpful.<br> <br></div>So I think I willl be spending this morning in <br><a href="https://github.com/OpenLiberty/liberty-arquillian/blob/master/liberty-managed/src/main/java/org/jboss/arquillian/container/was/wlp_managed_8_5/WLPManagedContainer.java">https://github.com/OpenLiberty/liberty-arquillian/blob/master/liberty-managed/src/main/java/org/jboss/arquillian/container/was/wlp_managed_8_5/WLPManagedContainer.java</a><br></div>and looking at Liberty FFDC files to build some caused by exception chains in the Liberty Arquillian Container.<br><br></div><div>I have to admit I had been through the weld core's ShouldThrow logic. <br></div><div>It was really helpful to understand what the cultural concensus/expectation for<br></div><div>a TCK @ShouldThrow is, in terms of:<br><br></div><div>Q1) @ShouldThrows identify one exception but servers usually report a causal chain -<br></div><div>was it OK for the ShouldThrow exception to be in the causal chain or does it have to be<br></div><div>the 'top' one. (and what does 'top' mean anyway when the interface is not code but<br></div><div>a set of messages in a log.) <br>A1) Clearly it is OK - "It should be thrown" - so it can be a member of a set<br></div><div>that is thrown - there is no customer Java involved in catching - just log messages<br></div><div>and these log messages should clearly state, for example "DefinitionException".<br></div><div><br>Q2) In terms of the exact exception thrown was the 'isa' (isAssignable) test acceptable?<br></div><div>(again this is code but the user interface is log messages)<br></div><div>A2) Clearly everyone uses Arquillian so that impl is the de-facto standard. However it<br></div><div>is also accepted practice that a Container or for a ExceptionTransformer might wrap<br></div><div>a, for example WELD DefinitionException with a javax.inject one - it has to<br></div><div>create 100% of the exceptions and usually wraps them up as a cause to an Arquillian <br>envelope exception anyway.<br></div><div></div><div><br></div><div>Reading the Weld code, I had thought I could get away with no ExceptionTransformer for now<br></div><div>as long as one of the causal exception chain was assignable from what was<br></div><div>sought (which I think is the case I have).<br></div><div><br></div><div>Thanks so much again - this has made my path ahead clear.<br></div><br><div>Gordon<br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 27 April 2018 at 07:54, Matej Novotny <span dir="ltr"><<a href="mailto:manovotn@redhat.com" target="_blank">manovotn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
----- Original Message -----<br>
> From: "Martin Kouba" <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>><br>
> To: "Matej Novotny" <<a href="mailto:manovotn@redhat.com">manovotn@redhat.com</a>>, "Gordon Hutchison" <<a href="mailto:gordon.hutchison@gmail.com">gordon.hutchison@gmail.com</a>><br>
> Cc: <a href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br>
> Sent: Friday, April 27, 2018 8:41:45 AM<br>
> Subject: Re: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMet<wbr>hodTest failure - ShouldThrow...Definition or<br>
> Deployment Exception? - spec inconsistency??<br>
> <br>
</span><span class="">> Dne 27.4.2018 v 08:26 Matej Novotny napsal(a):<br>
> > Hi Gordon,<br>
> > <br>
> > running the test on WFLY (or actually without EE container) gives me the<br>
> > same stacktrace, however the test passes for me.<br>
> > What is it you fail on exactly?<br>
> > <br>
> > Debugging a bit shows that @ShouldThrowException annotation (which is<br>
> > guarding the exception in the test) goes through a whole chain of<br>
> > exceptions - having it wrapped should still pass the test.<br>
> > E.g. it looks at the cause, see if that's assignable, and if it isn't then<br>
> > the method is recursively invoked for Exception.getCause().<br>
> > Here is a link to Arq. code doing that -<br>
> > <a href="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" rel="noreferrer" target="_blank">https://github.com/arquillian/<wbr>arquillian-core/blob/master/<wbr>container/impl-base/src/main/<wbr>java/org/jboss/arquillian/<wbr>container/impl/client/<wbr>container/<wbr>DeploymentExceptionHandler.<wbr>java#L63-L66</a><br>
> <br>
> <br>
> In fact, we're using a customized<br>
> org.jboss.arquillian.<wbr>container.spi.client.<wbr>container.<wbr>DeploymentExceptionTransformer<br>
> for WildFly:<br>
> <a href="https://github.com/weld/core/blob/master/jboss-tck-runner/src/test/java/org/jboss/weld/tck/wildfly8/WildFly8DeploymentExceptionTransformer.java" rel="noreferrer" target="_blank">https://github.com/weld/core/<wbr>blob/master/jboss-tck-runner/<wbr>src/test/java/org/jboss/weld/<wbr>tck/wildfly8/<wbr>WildFly8DeploymentExceptionTra<wbr>nsformer.java</a><br>
<br>
</span>Yea, I know.<br>
But this does not take effect outside WildFly where the result is the same.<br>
And even in WFLY it repacks Arquillian-specific exception (org.jboss.arquillian.<wbr>container.spi.client.<wbr>container.DeploymentException) into whatever fragment it finds in getCause().<br>
<div class="HOEnZb"><div class="h5"><br>
> <br>
> > <br>
> > As for spec point of view...<br>
> > Wrapping those exceptions meets both criteria mentioned in spec as long as<br>
> > you can get to both of them.<br>
> > Also, having DefinitionException on top makes sense from user point of view<br>
> > (at least in my opinion) because is it ultimately developer's mistake that<br>
> > he/she did not add the notify() method.<br>
> > And that subsequently leads to DeploymentException.<br>
> > Does it make sense?<br>
> > <br>
> > I'd like to help more but I am not sure whether you are battling some<br>
> > actual test failure or the somewhat clashing sentences in spec itself?<br>
> > <br>
> > Matej<br>
> > <br>
> > ----- Original Message -----<br>
> >> From: "Gordon Hutchison" <<a href="mailto:gordon.hutchison@gmail.com">gordon.hutchison@gmail.com</a>><br>
> >> To: <a href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br>
> >> Sent: Thursday, April 26, 2018 5:17:55 PM<br>
> >> Subject: [weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMet<wbr>hodTest<br>
> >> failure - ShouldThrow...Definition or<br>
> >> Deployment Exception? - spec inconsistency??<br>
> >><br>
> >> Hi Folks,<br>
> >><br>
> >> I work in the IBM CDI implementation team.<br>
> >><br>
> >> We are running the CDI 2.0 TCK/CDS and get a test failure on:<br>
> >><br>
> >> org.jboss.cdi.tck.tests.<wbr>extensions.lifecycle.broken.<wbr>observerMethod.<wbr>ObserverMethodWithoutNotifyMet<wbr>hodTest<br>
> >><br>
> >> that I need some advice on.<br>
> >><br>
> >> The test has:<br>
> >><br>
> >> import <a href="http://javax.enterprise.inject.spi.De" rel="noreferrer" target="_blank">javax.enterprise.inject.spi.De</a> ploymentException;<br>
> >><br>
> >> @ShouldThrowException(<wbr>DeploymentException.class)<br>
> >><br>
> >><br>
> >> // unable to process ObserverMethodConfigurator due to missing notify<br>
> >> method<br>
> >> impl<br>
> >> @Test<br>
> >> @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id =<br>
> >> "ee")<br>
> >> })<br>
> >> public void unableToProcessObserverMethodC<wbr>onfigurator() {<br>
> >> }<br>
> >><br>
> >> This behaviour is specified in<br>
> >> <a href="https://docs.jboss.org/cdi/spec/2.0/cdi-spec-with-assertions.html#after_bean_discovery" rel="noreferrer" target="_blank">https://docs.jboss.org/cdi/<wbr>spec/2.0/cdi-spec-with-<wbr>assertions.html#after_bean_<wbr>discovery</a><br>
> >> (search for "ee)" )<br>
> >><br>
> >> ee) If the container is unable to process the ObserverMethodConfigurator<br>
> >> it<br>
> >> automatically detects the problem and treats it as a deployment problem.<br>
> >> ObserverMethodWithoutNotifyMet<wbr>hodTest.<wbr>unableToProcessObserverMethodC<wbr>onfigurator()<br>
> >><br>
> >><br>
> >> However what we see coming back from Weld is not a javax<br>
> >> DeploymentException<br>
> >> but a javax DefinitionException wrapping a weld DeploymentException cause<br>
> >><br>
> >> Stack Dump = <a href="http://javax.enterprise.inject.spi.De" rel="noreferrer" target="_blank">javax.enterprise.inject.spi.De</a> finitionException:<br>
> >> org.jboss.weld.exceptions.<wbr>DeploymentException: WELD-000179:<br>
> >> ObserverMethodConfigurator created by<br>
> >> org.jboss.cdi.tck.tests.<wbr>extensions.lifecycle.broken.<wbr>observerMethod.<wbr>AfterBeanDiscoveryObserver@<wbr>d31423c<br>
> >> cannot be processed<br>
> >> at<br>
> >> org.jboss.weld.bootstrap.<wbr>events.AfterBeanDiscoveryImpl.<wbr>finish(AfterBeanDiscoveryImpl.<wbr>java:180)<br>
> >> <<<<<<< Problem????<br>
> >> at<br>
> >> org.jboss.weld.bootstrap.<wbr>events.AfterBeanDiscoveryImpl.<wbr>fire(AfterBeanDiscoveryImpl.<wbr>java:76)<br>
> >> at org.jboss.weld.bootstrap.<wbr>WeldStartup.deployBeans(<wbr>WeldStartup.java:446)<br>
> >> at<br>
> >> org.jboss.weld.bootstrap.<wbr>WeldBootstrap.deployBeans(<wbr>WeldBootstrap.java:83)<br>
> >> at<br>
> >> com.ibm.ws.cdi.impl.<wbr>CDIContainerImpl.<wbr>startInitialization(<wbr>CDIContainerImpl.java:149)<br>
> >> at<br>
> >> com.ibm.ws.cdi.liberty.<wbr>CDIRuntimeImpl.<wbr>applicationStarting(<wbr>CDIRuntimeImpl.java:400)<br>
> >> at<br>
> >> com.ibm.ws.container.service.<wbr>state.internal.<wbr>ApplicationStateManager.<wbr>fireStarting(<wbr>ApplicationStateManager.java:<wbr>28)<br>
> >> at<br>
> >> com.ibm.ws.container.service.<wbr>state.internal.<wbr>StateChangeServiceImpl.<wbr>fireApplicationStarting(<wbr>StateChangeServiceImpl.java:<wbr>50)<br>
> >> at<br>
> >> com.ibm.ws.app.manager.module.<wbr>internal.DeployedAppInfoBase.<wbr>preDeployApp(<wbr>DeployedAppInfoBase.java:383)<br>
> >> at<br>
> >> com.ibm.ws.app.manager.module.<wbr>internal.DeployedAppInfoBase.<wbr>deployApp(DeployedAppInfoBase.<wbr>java:412)<br>
> >> at <a href="http://com.ibm.ws.app.manager.war.int" rel="noreferrer" target="_blank">com.ibm.ws.app.manager.war.int</a><br>
> >> ernal.<wbr>WARApplicationHandlerImpl.<wbr>install(<wbr>WARApplicationHandlerImpl.<wbr>java:65)<br>
> >> at<br>
> >> com.ibm.ws.app.manager.<wbr>internal.statemachine.<wbr>StartAction.execute(<wbr>StartAction.java:140)<br>
> >> at<br>
> >> com.ibm.ws.app.manager.<wbr>internal.statemachine.<wbr>ApplicationStateMachineImpl.<wbr>enterState(<wbr>ApplicationStateMachineImpl.<wbr>java:1258)<br>
> >> at<br>
> >> com.ibm.ws.app.manager.<wbr>internal.statemachine.<wbr>ApplicationStateMachineImpl.<wbr>run(<wbr>ApplicationStateMachineImpl.<wbr>java:873)<br>
> >> at<br>
> >> java.util.concurrent.<wbr>ThreadPoolExecutor.runWorker(<wbr>ThreadPoolExecutor.java:1149)<br>
> >> at<br>
> >> java.util.concurrent.<wbr>ThreadPoolExecutor$Worker.run(<wbr>ThreadPoolExecutor.java:624)<br>
> >> at java.lang.Thread.run(Thread.<wbr>java:748)<br>
> >> Caused by: org.jboss.weld.exceptions.<wbr>DeploymentException: WELD-000179:<br>
> >> ObserverMethodConfigurator created by<br>
> >> org.jboss.cdi.tck.tests.<wbr>extensions.lifecycle.broken.<wbr>observerMethod.<wbr>AfterBeanDiscoveryObserver@<wbr>d31423c<br>
> >> cannot be processed<br>
> >> at<br>
> >> org.jboss.weld.bootstrap.<wbr>events.AfterBeanDiscoveryImpl$<wbr>ObserverRegistration.<wbr>initObserverMethod(<wbr>AfterBeanDiscoveryImpl.java:<wbr>368)<br>
> >> at<br>
> >> org.jboss.weld.bootstrap.<wbr>events.AfterBeanDiscoveryImpl.<wbr>processObserverRegistration(<wbr>AfterBeanDiscoveryImpl.java:<wbr>268)<br>
> >> at<br>
> >> org.jboss.weld.bootstrap.<wbr>events.AfterBeanDiscoveryImpl.<wbr>finish(AfterBeanDiscoveryImpl.<wbr>java:177)<br>
> >> ... 16 more<br>
> >> Caused by: org.jboss.weld.exceptions.<wbr>DefinitionException: WELD-000415:<br>
> >> Custom<br>
> >> implementation of observer method does not override either notify(T) or<br>
> >> notify(EventContext<T>):<br>
> >> org.jboss.weld.bootstrap.<wbr>events.configurator.<wbr>ObserverMethodConfiguratorImpl<wbr>@7e164c01<br>
> >> at<br>
> >> org.jboss.weld.bootstrap.<wbr>events.configurator.<wbr>ObserverMethodConfiguratorImpl<wbr>$ImmutableObserverMethod.<<wbr>init>(<wbr>ObserverMethodConfiguratorImpl<wbr>.java:272)<br>
> >> at<br>
> >> org.jboss.weld.bootstrap.<wbr>events.configurator.<wbr>ObserverMethodConfiguratorImpl<wbr>.complete(<wbr>ObserverMethodConfiguratorImpl<wbr>.java:234)<br>
> >> at<br>
> >> org.jboss.weld.bootstrap.<wbr>events.AfterBeanDiscoveryImpl$<wbr>ObserverRegistration.<wbr>initObserverMethod(<wbr>AfterBeanDiscoveryImpl.java:<wbr>366)<br>
> >> ... 18 more<br>
> >><br>
> >><br>
> >> We can see the AfterBeanDiscoveryImpl.java:<wbr>180 being<br>
> >><br>
> >> /**<br>
> >> * Bean and observer registration is delayed until after all {@link<br>
> >> AfterBeanDiscovery} observers are notified.<br>
> >> */<br>
> >> private void finish() {<br>
> >> try {<br>
> >> GlobalEnablementBuilder globalEnablementBuilder =<br>
> >> getBeanManager().getServices()<wbr>.get(GlobalEnablementBuilder.<wbr>class);<br>
> >> for (BeanRegistration registration : additionalBeans) {<br>
> >> processBeanRegistration(<wbr>registration, globalEnablementBuilder);<br>
> >> }<br>
> >> for (ObserverRegistration registration : additionalObservers) {<br>
> >> processObserverRegistration(<wbr>registration);<br>
> >> }<br>
> >> } catch (Exception e) {<br>
> >> throw new DefinitionException(e); <<<<<< line 180<br>
> >> }<br>
> >> }<br>
> >><br>
> >><br>
> >> I am also aware of, in <a href="http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf" rel="noreferrer" target="_blank">http://docs.jboss.org/cdi/<wbr>spec/2.0/cdi-spec.pdf</a><br>
> >> 11.5.3.,<br>
> >> "If any observer method of the AfterBeanDiscovery event throws an<br>
> >> exception,<br>
> >> the exception is treated as a definition error by the container"<br>
> >><br>
> >> So why is the test expecting DeploymentException<br>
> >><br>
> >> import <a href="http://javax.enterprise.inject.spi.De" rel="noreferrer" target="_blank">javax.enterprise.inject.spi.De</a> ploymentException;<br>
> >> ... @ShouldThrowException(<wbr>DeploymentException.class)<br>
> >><br>
> >><br>
> >> It seems like the test is seeing<br>
> >> @SpecAssertions({ @SpecAssertion(section = AFTER_BEAN_DISCOVERY, id =<br>
> >> "ee")<br>
> >> })<br>
> >> If the container is unable to process the ObserverMethodConfigurator it<br>
> >> automatically detects the problem and treats it as a deployment problem.<br>
> >> as dominant but the weld implementation is seeing<br>
> >> <a href="http://docs.jboss.org/cdi/spec/2.0/cdi-spec.pdf" rel="noreferrer" target="_blank">http://docs.jboss.org/cdi/<wbr>spec/2.0/cdi-spec.pdf</a> : 11.5.3<br>
> >> If any observer method of the AfterBeanDiscovery event throws an<br>
> >> exception,<br>
> >> the exception is treated as a definition error by the container"<br>
> >> as dominant.<br>
> >><br>
> >> ....and the two do not agree.<br>
> >><br>
> >> So the bottom line is the CDI CTS/TCK test<br>
> >> org.jboss.cdi.tck.tests.<wbr>extensions.lifecycle.broken.<wbr>observerMethod.<wbr>ObserverMethodWithoutNotifyMet<wbr>hodTest<br>
> >> fails due to the inconsistency.<br>
> >><br>
> >> Have I missunderstood the spec contradiction or missed some part of Weld<br>
> >> integration needed?<br>
> >><br>
> >> Gordon Hutchison<br>
> >><br>
> >> ______________________________<wbr>_________________<br>
> >> weld-dev mailing list<br>
> >> <a href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/weld-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/weld-dev</a><br>
> > ______________________________<wbr>_________________<br>
> > weld-dev mailing list<br>
> > <a href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/weld-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/weld-dev</a><br>
> > <br>
> <br>
> --<br>
> Martin Kouba<br>
> Senior Software Engineer<br>
> Red Hat, Czech Republic<br>
> <br>
</div></div></blockquote></div><br></div>