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@redhat.com> wrote:


----- Original Message -----
> From: "Martin Kouba" <mkouba@redhat.com>
> To: "Matej Novotny" <manovotn@redhat.com>, "Gordon Hutchison" <gordon.hutchison@gmail.com>
> Cc: weld-dev@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@gmail.com>
> >> To: weld-dev@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@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@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@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@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/weld-dev
> > _______________________________________________
> > weld-dev mailing list
> > weld-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/weld-dev
> >
>
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
>