----- Original Message ----- > From: "Martin Kouba" <[email protected]> > To: "Matej Novotny" <[email protected]>, "Gordon Hutchison" > <[email protected]> > Cc: [email protected] > 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" <[email protected]> > >> To: [email protected] > >> 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 > >> [email protected] > >> https://lists.jboss.org/mailman/listinfo/weld-dev > > _______________________________________________ > > weld-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
