[weld-dev] CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest failure - ShouldThrow...Definition or Deployment Exception? - spec inconsistency??

Fri Apr 27 02:54:02 EDT 2018

----- 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
> 