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 -
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(a)gmail.com>
To: weld-dev(a)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_b...
(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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev