[JBoss JIRA] (ARQ-2047) Use of Java 8 lambdas by injected class causes injection to fail silently
by Colin Thorburn (JIRA)
Colin Thorburn created ARQ-2047:
-----------------------------------
Summary: Use of Java 8 lambdas by injected class causes injection to fail silently
Key: ARQ-2047
URL: https://issues.jboss.org/browse/ARQ-2047
Project: Arquillian
Issue Type: Feature Request
Components: Base Implementation
Affects Versions: 1.1.11.Final
Environment: Eclipse Neon, Windows
Reporter: Colin Thorburn
Have seen this bug elsewhere marked as resolved but it clearly isn't.
To reproduce simply create a Junit 4 Arquiliian test in which EntityManager and UserTransaction fields are annontated for injection.
Devise an @Test method contriving the use of (say) Runnable. Call a method in another class using the Runnable as a parameter
Code using an anonymous inner class idiom; everything works fine.
Code it as a lambda expression and, bizarrely, only the EntityManager is not injected (utx is OK!). No hint of anything awry in the log, no exception thrown, field is simply left null.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (ARQ-2034) Test enrichment and JUnit @Rule do not harmonize
by Björn Kautler (JIRA)
[ https://issues.jboss.org/browse/ARQ-2034?page=com.atlassian.jira.plugin.s... ]
Björn Kautler commented on ARQ-2034:
------------------------------------
[~mjobanek] Are you sure? As far as I remember what I have looked at in Arquillian code you copied some code from the {{BlockJUnit4ClassRunner}}, having own instances of {{withBefore}}, {{withAfter}} and so on, but calling the {{BlockJUnit4ClassRunner}}s {{withRules}} method via reflection. In the {{withRules}} you should also have a test available already I think, as that probably is the code that sets the instance fields that are annotated with {{@Rule}} to the actual rule instances. So I guess you have to change that you not hook into {{withBefore}} but already into {{withRules}} to do the enriching before the rules.
> Test enrichment and JUnit @Rule do not harmonize
> ------------------------------------------------
>
> Key: ARQ-2034
> URL: https://issues.jboss.org/browse/ARQ-2034
> Project: Arquillian
> Issue Type: Bug
> Components: Base Implementation
> Affects Versions: 1.1.11.Final
> Environment: junit 4.11
> arquillian-junit-container 1.1.11.Final
> wildfly-arquillian-container-remote 8.1.0.Final
> Reporter: Björn Kautler
> Assignee: Matous Jobanek
>
> We are starting with Arquillian tests on a remote WildFly instance.
> I tried to write a JUnit {{@Rule}}, that can be used to make a login call for all test methods automatically, but I was not yet able to make it work, as I need an injected {{@Ejb}} instance for this.
> I tried to add {{@EJB private InterfaceLoginManagement interfaceLoginManagement;}} to the {{TestRule}} implementation, but it stays {{null}}. I've read at ARQ-1954 that this should probably work, but unfortunately it is not, at least not with the remote container runner. {{org.jboss.arquillian.junit.extension.JUnitCoreExtension}} that should register {{org.jboss.arquillian.junit.extension.UpdateTestResultBeforeAfter}} and {{org.jboss.arquillian.junit.RulesEnricher}} is not even loaded on the container side. Maybe the {{META-INF/services/}} file is missing?
> Then I tried to simply give the injected instance to the rule from the test class like
> {code}
> @EJB private InterfaceLoginManagement interfaceLoginManagement;
> @Rule private LoginRule loginRule = new LoginRule(interfaceLoginManagement);
> {code}
> or even
> {code}
> @EJB private InterfaceLoginManagement interfaceLoginManagement;
> @Rule public LoginRule getLoginRule() {
> return new LoginRule(() -> {
> return interfaceLoginManagement;
> });
> }
> {code}
> with the {{LoginRule}} receiving a {{Supplier<InterfaceLoginManagement>}} and call it as late as possible, i. e. in the rules {{apply()}} method. But even this is still too early as the EJB is still {{null}} and the test enrichers are only run between the {{@Rule}} applying and {{@Before}} methods.
> So I'd like to suggest two things:
> # Fix the implementation of ARQ-1954 if it should work on container side which I assume it should
> # Make the test enrichments earlier in the lifecycle, i. e. before the {{@Rule}} s are being applied, or rather even before the {{@Rule}} methods are called, so that you at least can use the injected instances in the {{@Rule}} annotated methods to forward them to a rule. This is necessary even if top 1 is taken care of, because you might want to use a 3rd Party rule the code of which you cannot change.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (ARQ-2046) CDI Injection in methods should only inject @Inject parameters
by S Haster (JIRA)
S Haster created ARQ-2046:
-----------------------------
Summary: CDI Injection in methods should only inject @Inject parameters
Key: ARQ-2046
URL: https://issues.jboss.org/browse/ARQ-2046
Project: Arquillian
Issue Type: Bug
Components: Runtime Enricher SPI
Affects Versions: 1.1.11.Final
Environment: git bash (mingw64) or eclipse, on windows 10
Reporter: S Haster
Attachments: testcase.tar.gz
The CDIInjectionEnricher should only inject method parameters annotated with @Inject, as is the spec and as it does with instance variables.
The current implementation, which treats every method parameter as an injection point, conflicts with custom test enrichers. If my project is a beanarchive with bean-discovery-mode=all then every class is counted as a bean.
If I have a testmethod where a custom enricher supplies one of the parameters the CDIInjectionEnricher also provides that parameter but by calling it's default parameter and not setting any other configuration, resulting in faulty testdata.
Even worse, because the ordering of TestEnrichers as used in LocalTestExecutor#enrichArguments is not defined, sometimes the bean provided by the custom enricher will be used, and sometimes the one provided by CDIInjectionEnricher, leading to a testcase that will only fail *sometimes*.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (ARQ-2041) Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/ARQ-2041?page=com.atlassian.jira.plugin.s... ]
Tomas Remes commented on ARQ-2041:
----------------------------------
I realized that it basically means starting of 2 Weld/CDI containers (this means to set different ids to containers otherwise it's not supported). Anyway it's irrelevant to this issue so please feel free to file another one.
> Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider
> ----------------------------------------------------------------------------------
>
> Key: ARQ-2041
> URL: https://issues.jboss.org/browse/ARQ-2041
> Project: Arquillian
> Issue Type: Bug
> Components: Weld Containers
> Reporter: Martin Kouba
> Assignee: Tomas Remes
> Fix For: weld_2.0.0.Beta3
>
>
> {{org.jboss.weld.servlet.StaticWeldProvider}} is not used in Weld since 2.2.5.Final. Actually, the class was removed from master branch (Weld 3) and 2.4 branch (soon current stable).
> The adapter should probably implement its own {{CDIProvider}} to support the simulated environments properly.
> Affects 2.0.0.Beta2 and 1.0.0.CR9.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (ARQ-2041) Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider
by John Ament (JIRA)
[ https://issues.jboss.org/browse/ARQ-2041?page=com.atlassian.jira.plugin.s... ]
John Ament commented on ARQ-2041:
---------------------------------
Hmm if that were the case, I would expect the same behavior for all three (Tomcat, Jetty, Undertow). This issue only occurs with Tomcat.
> Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider
> ----------------------------------------------------------------------------------
>
> Key: ARQ-2041
> URL: https://issues.jboss.org/browse/ARQ-2041
> Project: Arquillian
> Issue Type: Bug
> Components: Weld Containers
> Reporter: Martin Kouba
> Assignee: Tomas Remes
> Fix For: weld_2.0.0.Beta3
>
>
> {{org.jboss.weld.servlet.StaticWeldProvider}} is not used in Weld since 2.2.5.Final. Actually, the class was removed from master branch (Weld 3) and 2.4 branch (soon current stable).
> The adapter should probably implement its own {{CDIProvider}} to support the simulated environments properly.
> Affects 2.0.0.Beta2 and 1.0.0.CR9.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (ARQ-2041) Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/ARQ-2041?page=com.atlassian.jira.plugin.s... ]
Tomas Remes commented on ARQ-2041:
----------------------------------
[~meetoblivion] Hi, well it's a synchronization problem, but I don't think it's a Weld or Arquillian problem. It's quite clear if you look at following jstack output (picked only the interesting part):
{noformat}
"localhost-startStop-1" #22 daemon prio=5 os_prio=0 tid=0x00007f8970004000 nid=0x4c83 waiting for monitor entry [0x00007f89c4d46000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.jboss.weld.servlet.HttpContextLifecycle.contextInitialized(HttpContextLifecycle.java:143)
- waiting to lock <0x0000000709bc25d8> (a org.jboss.weld.Container)
at org.jboss.weld.servlet.WeldInitialListener.contextInitialized(WeldInitialListener.java:105)
at org.jboss.weld.servlet.api.helpers.ForwardingServletListener.contextInitialized(ForwardingServletListener.java:34)
at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:122)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4727)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5189)
- locked <0x0000000709bc3b10> (a org.apache.catalina.core.StandardContext)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
- locked <0x0000000709bc3b10> (a org.apache.catalina.core.StandardContext)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1403)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1393)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
"main" #1 prio=5 os_prio=0 tid=0x00007f89f800b000 nid=0x4c22 waiting on condition [0x00007f8a00de2000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0000000783c825e8> (a java.util.concurrent.FutureTask)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:911)
- locked <0x0000000709bc37f8> (a org.apache.catalina.core.StandardEngine)
at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262)
- locked <0x0000000709bc37f8> (a org.apache.catalina.core.StandardEngine)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
- locked <0x0000000709bc37f8> (a org.apache.catalina.core.StandardEngine)
at org.apache.catalina.core.StandardService.startInternal(StandardService.java:422)
- locked <0x0000000709bc37f8> (a org.apache.catalina.core.StandardEngine)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
- locked <0x0000000709bc2d48> (a org.apache.catalina.core.StandardService)
at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:791)
- locked <0x0000000709bc6ae0> (a java.lang.Object)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
- locked <0x0000000709bc2920> (a org.apache.catalina.core.StandardServer)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:356)
at ws.ament.hammock.web.tomcat.TomcatWebServer.start(TomcatWebServer.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
at ws.ament.hammock.web.spi.WebServer$557810379$Proxy$_$$_WeldClientProxy.start(Unknown Source)
at ws.ament.hammock.web.spi.StartWebServer.init(StartWebServer.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
at org.jboss.weld.injection.MethodInvocationStrategy$SpecialParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124)
- locked <0x0000000709bc25d8> (a org.jboss.weld.Container)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:277)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:255)
at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:269)
at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:258)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:154)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:148)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35)
at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:458)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
- locked <0x0000000709c46b70> (a org.jboss.weld.bootstrap.WeldBootstrap)
at org.jboss.arquillian.container.weld.embedded.mock.TestContainer.startContainer(TestContainer.java:240)
at org.jboss.arquillian.container.weld.embedded.WeldMockContainer.deploy(WeldMockContainer.java:115)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
{noformat}
TestContainer starts initialization and you start your {{WebServer}} (in this case Tomcat) during {{AfterDeploymentValidation}}. In this moment weld-servlet comes to the game, but please note the first TestContainer has not finished initialization yet. I don't consider this as a valid usage. As CDI spec states (for {{AfterDeploymentValidation}} event):
{quote}
The container must not allow any request to be processed by the deployment until all observers of this
event return.
{quote}
> Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider
> ----------------------------------------------------------------------------------
>
> Key: ARQ-2041
> URL: https://issues.jboss.org/browse/ARQ-2041
> Project: Arquillian
> Issue Type: Bug
> Components: Weld Containers
> Reporter: Martin Kouba
> Assignee: Tomas Remes
> Fix For: weld_2.0.0.Beta3
>
>
> {{org.jboss.weld.servlet.StaticWeldProvider}} is not used in Weld since 2.2.5.Final. Actually, the class was removed from master branch (Weld 3) and 2.4 branch (soon current stable).
> The adapter should probably implement its own {{CDIProvider}} to support the simulated environments properly.
> Affects 2.0.0.Beta2 and 1.0.0.CR9.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (ARQ-2041) Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider
by John Ament (JIRA)
[ https://issues.jboss.org/browse/ARQ-2041?page=com.atlassian.jira.plugin.s... ]
John Ament commented on ARQ-2041:
---------------------------------
The original that I reported still seems to be an issue, even after making this change. It seems to be alittle different though. Either I have logging off, or the repeated errors are gone.
Easiest way to reproduce is to run https://github.com/hammock-project/hammock/blob/master/rest-spark/pom.xml... . {{mvn clean install -Ptomcat-test}}. From debugging, it seems like tomcat never completes loading. I do see it going in a loop though.
> Arquillian Weld container should not use org.jboss.weld.servlet.StaticWeldProvider
> ----------------------------------------------------------------------------------
>
> Key: ARQ-2041
> URL: https://issues.jboss.org/browse/ARQ-2041
> Project: Arquillian
> Issue Type: Bug
> Components: Weld Containers
> Reporter: Martin Kouba
> Assignee: Tomas Remes
> Fix For: weld_2.0.0.Beta3
>
>
> {{org.jboss.weld.servlet.StaticWeldProvider}} is not used in Weld since 2.2.5.Final. Actually, the class was removed from master branch (Weld 3) and 2.4 branch (soon current stable).
> The adapter should probably implement its own {{CDIProvider}} to support the simulated environments properly.
> Affects 2.0.0.Beta2 and 1.0.0.CR9.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months