CDI 2.0 TCK ObserverMethodWithoutNotifyMethodTest failure - ShouldThrow...Definition or Deployment Exception? - spec inconsistency??
5:17 p.m.
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.observer
Method.ObserverMethodWithoutNotifyMethodTest
that I need some advice on.
The test has:
import javax.enterprise.inject.spi.DeploymentException;
@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.unableToProcessObserve
rMethodConfigurator()
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.DefinitionException:
org.jboss.weld.exceptions.DeploymentException: WELD-000179:
ObserverMethodConfigurator created by org.jboss.cdi.tck.tests.extens
ions.lifecycle.broken.observerMethod.AfterBeanDiscoveryObserver@d31423c
cannot be processed
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finis
h(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.ApplicationState
Manager.fireStarting(ApplicationStateManager.java:28)
at com.ibm.ws.container.service.state.internal.StateChangeServi
ceImpl.fireApplicationStarting(StateChangeServiceImpl.java:50)
at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.p
reDeployApp(DeployedAppInfoBase.java:383)
at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.d
eployApp(DeployedAppInfoBase.java:412)
at com.ibm.ws.app.manager.war.internal.WARApplicationHandlerImp
l.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.ApplicationStat
eMachineImpl.enterState(ApplicationStateMachineImpl.java:1258)
at com.ibm.ws.app.manager.internal.statemachine.ApplicationStat
eMachineImpl.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.extens
ions.lifecycle.broken.observerMethod.AfterBeanDiscoveryObserver@d31423c
cannot be processed
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$Obser
verRegistration.initObserverMethod(AfterBeanDiscoveryImpl.java:368)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.proce
ssObserverRegistration(AfterBeanDiscoveryImpl.java:268)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.finis
h(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.event
s.configurator.ObserverMethodConfiguratorImpl@7e164c01
at org.jboss.weld.bootstrap.events.configurator.ObserverMethodC
onfiguratorImpl$ImmutableObserverMethod.<init>(ObserverMethodConfiguratorImpl.java:272)
at org.jboss.weld.bootstrap.events.configurator.ObserverMethodC
onfiguratorImpl.complete(ObserverMethodConfiguratorImpl.java:234)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl$Obser
verRegistration.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.DeploymentException;
... @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.observer
Method.ObserverMethodWithoutNotifyMethodTest
fails due to the inconsistency.
Have I missunderstood the spec contradiction or missed some part of Weld
integration needed?
Gordon Hutchison
8:26 a.m.
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-...
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
8:41 a.m.
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-...
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/o...
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
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
8:54 a.m.
----- Original Message -----
From: "Martin Kouba" <mkouba(a)redhat.com>
To: "Matej Novotny" <manovotn(a)redhat.com>, "Gordon Hutchison"
<gordon.hutchison(a)gmail.com>
Cc: weld-dev(a)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-...
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/o...
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(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
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
11:26 a.m.
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-man...
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(a)redhat.com> wrote:
----- Original Message -----
> From: "Martin Kouba" <mkouba(a)redhat.com>
> To: "Matej Novotny" <manovotn(a)redhat.com>, "Gordon
Hutchison" <
gordon.hutchison(a)gmail.com>
> Cc: weld-dev(a)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/WildFly8DeploymentExceptionTra
nsformer.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(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_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.unableToProcessObserverMethodC
onfigurator()
> >>
> >>
> >> 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
> > _______________________________________________
> > weld-dev mailing list
> > weld-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/weld-dev
> >
>
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
>
2191
days inactive
2192
days old
4 comments
3 participants
participants (3)
-
Gordon Hutchison -
Martin Kouba -
Matej Novotny