From issues at jboss.org Wed Apr 1 02:04:19 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 1 Apr 2015 02:04:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-469) WebDriverWait.until() doesn't support Page Fragments that extend WebElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-469: ------------------------------ Fix Version/s: 2.1-Tracking > WebDriverWait.until() doesn't support Page Fragments that extend WebElement > --------------------------------------------------------------------------- > > Key: ARQGRA-469 > URL: https://issues.jboss.org/browse/ARQGRA-469 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Fix For: 2.1-Tracking > > Attachments: ARQGRA-469.patch > > > When using Page Fragments that extend the WebElement Interface (as described in http://arquillian.org/blog/2013/09/04/arquillian-graphene-2-0-0-Alpha5/) WebDriverWait.until().element().is().present() cannot be used, because the NoSuchElementException, that gets thrown, is encapsulated by an InvocationTargetException. Unfortunately this exception will not be ignored while waiting for the until() method to complete (see org.openqa.selenium.support.ui.FluentWait). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Apr 1 02:04:19 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 1 Apr 2015 02:04:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-469) WebDriverWait.until() doesn't support Page Fragments that extend WebElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-469: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-graphene/pull/129 > WebDriverWait.until() doesn't support Page Fragments that extend WebElement > --------------------------------------------------------------------------- > > Key: ARQGRA-469 > URL: https://issues.jboss.org/browse/ARQGRA-469 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Fix For: 2.1-Tracking > > Attachments: ARQGRA-469.patch > > > When using Page Fragments that extend the WebElement Interface (as described in http://arquillian.org/blog/2013/09/04/arquillian-graphene-2-0-0-Alpha5/) WebDriverWait.until().element().is().present() cannot be used, because the NoSuchElementException, that gets thrown, is encapsulated by an InvocationTargetException. Unfortunately this exception will not be ignored while waiting for the until() method to complete (see org.openqa.selenium.support.ui.FluentWait). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Apr 1 02:04:19 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 1 Apr 2015 02:04:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-469) WebDriverWait.until() doesn't support Page Fragments that extend WebElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055167#comment-13055167 ] Luk?? Fry? commented on ARQGRA-469: ----------------------------------- Rights, that's definitely a bug and it would even be worth to backport to 2.0.x > WebDriverWait.until() doesn't support Page Fragments that extend WebElement > --------------------------------------------------------------------------- > > Key: ARQGRA-469 > URL: https://issues.jboss.org/browse/ARQGRA-469 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Fix For: 2.1-Tracking > > Attachments: ARQGRA-469.patch > > > When using Page Fragments that extend the WebElement Interface (as described in http://arquillian.org/blog/2013/09/04/arquillian-graphene-2-0-0-Alpha5/) WebDriverWait.until().element().is().present() cannot be used, because the NoSuchElementException, that gets thrown, is encapsulated by an InvocationTargetException. Unfortunately this exception will not be ignored while waiting for the until() method to complete (see org.openqa.selenium.support.ui.FluentWait). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Apr 1 02:05:18 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 1 Apr 2015 02:05:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-469) WebDriverWait.until() doesn't support Page Fragments that extend WebElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-469: ------------------------------ Fix Version/s: 2.0-Tracking > WebDriverWait.until() doesn't support Page Fragments that extend WebElement > --------------------------------------------------------------------------- > > Key: ARQGRA-469 > URL: https://issues.jboss.org/browse/ARQGRA-469 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Fix For: 2.0-Tracking, 2.1-Tracking > > Attachments: ARQGRA-469.patch > > > When using Page Fragments that extend the WebElement Interface (as described in http://arquillian.org/blog/2013/09/04/arquillian-graphene-2-0-0-Alpha5/) WebDriverWait.until().element().is().present() cannot be used, because the NoSuchElementException, that gets thrown, is encapsulated by an InvocationTargetException. Unfortunately this exception will not be ignored while waiting for the until() method to complete (see org.openqa.selenium.support.ui.FluentWait). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Apr 1 02:08:18 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 1 Apr 2015 02:08:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-469) WebDriverWait.until() doesn't support Page Fragments that extend WebElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055168#comment-13055168 ] Luk?? Fry? commented on ARQGRA-469: ----------------------------------- Merged to master and 2.0.x, Thanks Michael! > WebDriverWait.until() doesn't support Page Fragments that extend WebElement > --------------------------------------------------------------------------- > > Key: ARQGRA-469 > URL: https://issues.jboss.org/browse/ARQGRA-469 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Fix For: 2.0-Tracking, 2.1-Tracking > > Attachments: ARQGRA-469.patch > > > When using Page Fragments that extend the WebElement Interface (as described in http://arquillian.org/blog/2013/09/04/arquillian-graphene-2-0-0-Alpha5/) WebDriverWait.until().element().is().present() cannot be used, because the NoSuchElementException, that gets thrown, is encapsulated by an InvocationTargetException. Unfortunately this exception will not be ignored while waiting for the until() method to complete (see org.openqa.selenium.support.ui.FluentWait). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Apr 1 02:08:19 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 1 Apr 2015 02:08:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-469) WebDriverWait.until() doesn't support Page Fragments that extend WebElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? reassigned ARQGRA-469: --------------------------------- Assignee: Michael Kotten > WebDriverWait.until() doesn't support Page Fragments that extend WebElement > --------------------------------------------------------------------------- > > Key: ARQGRA-469 > URL: https://issues.jboss.org/browse/ARQGRA-469 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Assignee: Michael Kotten > Fix For: 2.0-Tracking, 2.1-Tracking > > Attachments: ARQGRA-469.patch > > > When using Page Fragments that extend the WebElement Interface (as described in http://arquillian.org/blog/2013/09/04/arquillian-graphene-2-0-0-Alpha5/) WebDriverWait.until().element().is().present() cannot be used, because the NoSuchElementException, that gets thrown, is encapsulated by an InvocationTargetException. Unfortunately this exception will not be ignored while waiting for the until() method to complete (see org.openqa.selenium.support.ui.FluentWait). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Apr 1 02:09:18 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Wed, 1 Apr 2015 02:09:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-469) WebDriverWait.until() doesn't support Page Fragments that extend WebElement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luk?? Fry? updated ARQGRA-469: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > WebDriverWait.until() doesn't support Page Fragments that extend WebElement > --------------------------------------------------------------------------- > > Key: ARQGRA-469 > URL: https://issues.jboss.org/browse/ARQGRA-469 > Project: Arquillian Graphene > Issue Type: Bug > Components: core > Affects Versions: 2.0.3.Final, 2.1.0.Alpha2 > Reporter: Michael Kotten > Assignee: Michael Kotten > Fix For: 2.0-Tracking, 2.1-Tracking > > Attachments: ARQGRA-469.patch > > > When using Page Fragments that extend the WebElement Interface (as described in http://arquillian.org/blog/2013/09/04/arquillian-graphene-2-0-0-Alpha5/) WebDriverWait.until().element().is().present() cannot be used, because the NoSuchElementException, that gets thrown, is encapsulated by an InvocationTargetException. Unfortunately this exception will not be ignored while waiting for the until() method to complete (see org.openqa.selenium.support.ui.FluentWait). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Apr 2 11:35:19 2015 From: issues at jboss.org (Tomas Rohovsky (JIRA)) Date: Thu, 2 Apr 2015 11:35:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1940) arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 In-Reply-To: References: Message-ID: Tomas Rohovsky created ARQ-1940: ----------------------------------- Summary: arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 Key: ARQ-1940 URL: https://issues.jboss.org/browse/ARQ-1940 Project: Arquillian Issue Type: Bug Components: OSGi Containers Reporter: Tomas Rohovsky Assignee: Thomas Diesler Priority: Minor Attachments: surefire-reproducer.zip arquillian-osgi-bundle is not undeployed when executing a test with surefire-plugin 2.18. It works with older versions of surefire-plugin. A reproducer is attached. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Apr 2 11:35:19 2015 From: issues at jboss.org (Tomas Rohovsky (JIRA)) Date: Thu, 2 Apr 2015 11:35:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1940) arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Rohovsky updated ARQ-1940: -------------------------------- Attachment: surefire-reproducer.zip > arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 > --------------------------------------------------------------------------------- > > Key: ARQ-1940 > URL: https://issues.jboss.org/browse/ARQ-1940 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Tomas Rohovsky > Assignee: Thomas Diesler > Priority: Minor > Attachments: surefire-reproducer.zip > > > arquillian-osgi-bundle is not undeployed when executing a test with surefire-plugin 2.18. It works with older versions of surefire-plugin. A reproducer is attached. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Apr 2 11:45:19 2015 From: issues at jboss.org (Martin Basovnik (JIRA)) Date: Thu, 2 Apr 2015 11:45:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1865) Undeploy arquillian bundle after the test suite in JMXDeployableContainer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Basovnik updated ARQ-1865: --------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Undeploy arquillian bundle after the test suite in JMXDeployableContainer > ------------------------------------------------------------------------- > > Key: ARQ-1865 > URL: https://issues.jboss.org/browse/ARQ-1865 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Martin Basovnik > > Undeploy arquillian bundle after the test suite in JMXDeployableContainer -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Apr 7 09:46:20 2015 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 7 Apr 2015 09:46:20 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1941) Revise Weld EE embedded container In-Reply-To: References: Message-ID: Tomas Remes created ARQ-1941: -------------------------------- Summary: Revise Weld EE embedded container Key: ARQ-1941 URL: https://issues.jboss.org/browse/ARQ-1941 Project: Arquillian Issue Type: Enhancement Components: Weld Containers Reporter: Tomas Remes The Weld EE embededd container would deserve complete revision. Nobody has touched the code for quite a long time. The maven profiles for Weld versions have really old versions and are bit confusing. The Weld 3 version is slowly approaching and could be included (probably in separate branch). Currently I encountered problem with bean discovery mode. It's not possible to test with ANNOTATED mode because WeldEEMockContainer deploys always with flag "merge=true" which results in bean archive with mode ALL. I guess there will be more similar issues like this. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Apr 9 13:25:19 2015 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Thu, 9 Apr 2015 13:25:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1756) wlp-managed arquillian support for wlp server assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Poul reassigned ARQ-1756: --------------------------------- Assignee: Gerhard Poul > wlp-managed arquillian support for wlp server assembly > ------------------------------------------------------ > > Key: ARQ-1756 > URL: https://issues.jboss.org/browse/ARQ-1756 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: D K > Assignee: Gerhard Poul > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > https://github.com/arquillian/arquillian-container-was/tree/master/wlp-managed-8.5 > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Apr 9 13:41:18 2015 From: issues at jboss.org (Gerhard Poul (JIRA)) Date: Thu, 9 Apr 2015 13:41:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1756) wlp-managed arquillian support for wlp server assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057463#comment-13057463 ] Gerhard Poul commented on ARQ-1756: ----------------------------------- I have now used the ci.maven plugins to implement this for the integrated tests of the wlp-managed container itself; You can certainly easily use this as a template and I don't think there is any value in duplicating this functionality within the wlp-managed container. It works pretty painlessly other than that there is currently no "official" release, so I'll keep this on the test branch for the time being: https://github.com/gpoul/arquillian-container-was/tree/ARQ-1756 [~aslak] can you please check whether this might be appropriate for including this in the official package so we can run integration tests against the real runtime? > wlp-managed arquillian support for wlp server assembly > ------------------------------------------------------ > > Key: ARQ-1756 > URL: https://issues.jboss.org/browse/ARQ-1756 > Project: Arquillian > Issue Type: Feature Request > Components: WebSphere Containers > Reporter: D K > Assignee: Gerhard Poul > > Websphere liberty Maven plugin allows you to package a liberty server assembly and deploy it to repo Manager like Nexus: > https://github.com/WASdev/ci.maven#liberty-assembly > It would be good if the Liberty Arquillian container could be configured to download and use this liberty assembly. > https://github.com/arquillian/arquillian-container-was/tree/master/wlp-managed-8.5 > This mean each environment the tests run on would'nt need to be pre-installed with a Liberty server. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Apr 12 14:53:18 2015 From: issues at jboss.org (Dimitrios Kordas (JIRA)) Date: Sun, 12 Apr 2015 14:53:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1942) Duplicate PK encountered when using a ApplyScriptBefore script In-Reply-To: References: Message-ID: Dimitrios Kordas created ARQ-1942: ------------------------------------- Summary: Duplicate PK encountered when using a ApplyScriptBefore script Key: ARQ-1942 URL: https://issues.jboss.org/browse/ARQ-1942 Project: Arquillian Issue Type: Bug Components: Extension - Persistence Affects Versions: persistence_1.0.0.Alpha7, persistence_1.0.0.Alpha6 Environment: Windows 8.1 Home, WildFly 8.2.0 Final, jdk1.8.0.40 Reporter: Dimitrios Kordas Assignee: Bartosz Majsak I am trying to create tests for hibernate under WildFly 8.2.0. I can successfully create the war using Shrinkwrap, but when Arquillian tries to run the script i provided using the @ApplyScriptBefore annotation hibernate complains about duplicate primary keys even though all keys defined are sequential. I encounter this error for specific primary keys. For example 1. If i run the same script (only with an id of 2) multiple times it works. I have tested the same thing using yaml and json formats and it doesn't work either. INSERT INTO app_category(id, description, name) VALUES(1, 'entertainment apps', 'Entertainment'); INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(1,true,'com.facebook','Facebook',1); INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(2,true,'com.twitter','Twitter',1); INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(3,true,'com.instagram','Instagram',1); -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Apr 12 14:56:19 2015 From: issues at jboss.org (Dimitrios Kordas (JIRA)) Date: Sun, 12 Apr 2015 14:56:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1942) Duplicate PK encountered when using a ApplyScriptBefore script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058172#comment-13058172 ] Dimitrios Kordas commented on ARQ-1942: --------------------------------------- I should add the output of the test. ------------------------------------------------------------------------------- Test set: com.ebiscon.mdm.mdmserver.test.AppTest ------------------------------------------------------------------------------- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 20.226 sec <<< FAILURE! TestCreateApp(com.ebiscon.mdm.mdmserver.test.AppTest) Time elapsed: 7.113 sec <<< ERROR! javax.ejb.EJBTransactionRolledbackException: org.hibernate.exception.ConstraintViolationException: could not execute statement at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:439) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at com.ebiscon.mdm.mdmserver.dao.AppDao$$$view8.save(Unknown Source) at com.ebiscon.mdm.mdmserver.services.impl.AppServiceImpl.save(AppServiceImpl.java:96) 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.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at com.ebiscon.mdm.mdmserver.services.AppService$$$view49.save(Unknown Source) 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.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) at com.ebiscon.mdm.mdmserver.services.impl.AppService$750867534$Proxy$_$$_Weld$EnterpriseProxy$.save(Unknown Source) at com.ebiscon.mdm.mdmserver.test.AppTest.TestCreateApp(AppTest.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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) 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:135) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) 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:84) 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:65) 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.createTestContext(TestContextHandler.java:102) 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:135) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) at org.junit.runner.JUnitCore.run(JUnitCore.java:160) at org.junit.runner.JUnitCore.run(JUnitCore.java:138) at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:160) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:126) at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:90) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) 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) Caused by: javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: could not execute statement at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1683) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:1187) at org.jboss.as.jpa.container.AbstractEntityManager.persist(AbstractEntityManager.java:581) at com.ebiscon.mdm.mdmserver.dao.base.GenericDao.save(GenericDao.java:22) at com.ebiscon.mdm.mdmserver.dao.impl.AppDaoImpl.save(AppDaoImpl.java:76) 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.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) ... 216 more Caused by: org.jboss.arquillian.test.spi.ArquillianProxyException: org.hibernate.exception.ConstraintViolationException : could not execute statement [Proxied because : Original exception not deserilizable, ClassNotFoundException] at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:129) at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) at org.hibernate.id.IdentityGenerator$GetGeneratedKeysDelegate.executeAndExtract(IdentityGenerator.java:96) at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:58) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3032) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3558) at org.hibernate.action.internal.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:98) at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:490) at org.hibernate.engine.spi.ActionQueue.addResolvedEntityInsertAction(ActionQueue.java:195) at org.hibernate.engine.spi.ActionQueue.addInsertAction(ActionQueue.java:179) at org.hibernate.engine.spi.ActionQueue.addAction(ActionQueue.java:214) at org.hibernate.event.internal.AbstractSaveEventListener.addInsertAction(AbstractSaveEventListener.java:324) at org.hibernate.event.internal.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:288) at org.hibernate.event.internal.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:194) at org.hibernate.event.internal.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:125) at org.hibernate.jpa.event.internal.core.JpaPersistEventListener.saveWithGeneratedId(JpaPersistEventListener.java:84) at org.hibernate.event.internal.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:206) at org.hibernate.event.internal.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:149) at org.hibernate.event.internal.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:75) at org.hibernate.internal.SessionImpl.firePersist(SessionImpl.java:811) at org.hibernate.internal.SessionImpl.persist(SessionImpl.java:784) at org.hibernate.internal.SessionImpl.persist(SessionImpl.java:789) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:1181) ... 254 more Caused by: org.jboss.arquillian.test.spi.ArquillianProxyException: org.postgresql.util.PSQLException : ERROR: duplicate key value violates unique constraint "app_pkey" Detail: Key (id)=(1) already exists. [Proxied because : Original exception not deserilizable, ClassNotFoundException] at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2198) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1927) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:561) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:419) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:365) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) ... 275 more > Duplicate PK encountered when using a ApplyScriptBefore script > -------------------------------------------------------------- > > Key: ARQ-1942 > URL: https://issues.jboss.org/browse/ARQ-1942 > Project: Arquillian > Issue Type: Bug > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6, persistence_1.0.0.Alpha7 > Environment: Windows 8.1 Home, WildFly 8.2.0 Final, jdk1.8.0.40 > Reporter: Dimitrios Kordas > Assignee: Bartosz Majsak > > I am trying to create tests for hibernate under WildFly 8.2.0. > I can successfully create the war using Shrinkwrap, but when Arquillian tries to run the script i provided using the @ApplyScriptBefore annotation hibernate complains about duplicate primary keys even though all keys defined are sequential. > I encounter this error for specific primary keys. For example 1. > If i run the same script (only with an id of 2) multiple times it works. > I have tested the same thing using yaml and json formats and it doesn't work either. > INSERT INTO app_category(id, description, name) VALUES(1, 'entertainment apps', 'Entertainment'); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(1,true,'com.facebook','Facebook',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(2,true,'com.twitter','Twitter',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(3,true,'com.instagram','Instagram',1); -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Apr 12 16:06:18 2015 From: issues at jboss.org (Dimitrios Kordas (JIRA)) Date: Sun, 12 Apr 2015 16:06:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1942) Duplicate PK encountered when using a ApplyScriptBefore script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058175#comment-13058175 ] Dimitrios Kordas commented on ARQ-1942: --------------------------------------- I have tested the same issue with JSON/YAML/XML and @UsingDataSet and it still behaves the same way (PK constrains violation) > Duplicate PK encountered when using a ApplyScriptBefore script > -------------------------------------------------------------- > > Key: ARQ-1942 > URL: https://issues.jboss.org/browse/ARQ-1942 > Project: Arquillian > Issue Type: Bug > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6, persistence_1.0.0.Alpha7 > Environment: Windows 8.1 Home, WildFly 8.2.0 Final, jdk1.8.0.40 > Reporter: Dimitrios Kordas > Assignee: Bartosz Majsak > > I am trying to create tests for hibernate under WildFly 8.2.0. > I can successfully create the war using Shrinkwrap, but when Arquillian tries to run the script i provided using the @ApplyScriptBefore annotation hibernate complains about duplicate primary keys even though all keys defined are sequential. > I encounter this error for specific primary keys. For example 1. > If i run the same script (only with an id of 2) multiple times it works. > I have tested the same thing using yaml and json formats and it doesn't work either. > INSERT INTO app_category(id, description, name) VALUES(1, 'entertainment apps', 'Entertainment'); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(1,true,'com.facebook','Facebook',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(2,true,'com.twitter','Twitter',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(3,true,'com.instagram','Instagram',1); -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Apr 12 16:08:19 2015 From: issues at jboss.org (Dimitrios Kordas (JIRA)) Date: Sun, 12 Apr 2015 16:08:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1942) Duplicate PK encountered when using a ApplyScriptBefore script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058176#comment-13058176 ] Dimitrios Kordas commented on ARQ-1942: --------------------------------------- If the following XML is used which starts at primary key 2 instead of 1, the test works. > Duplicate PK encountered when using a ApplyScriptBefore script > -------------------------------------------------------------- > > Key: ARQ-1942 > URL: https://issues.jboss.org/browse/ARQ-1942 > Project: Arquillian > Issue Type: Bug > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6, persistence_1.0.0.Alpha7 > Environment: Windows 8.1 Home, WildFly 8.2.0 Final, jdk1.8.0.40 > Reporter: Dimitrios Kordas > Assignee: Bartosz Majsak > > I am trying to create tests for hibernate under WildFly 8.2.0. > I can successfully create the war using Shrinkwrap, but when Arquillian tries to run the script i provided using the @ApplyScriptBefore annotation hibernate complains about duplicate primary keys even though all keys defined are sequential. > I encounter this error for specific primary keys. For example 1. > If i run the same script (only with an id of 2) multiple times it works. > I have tested the same thing using yaml and json formats and it doesn't work either. > INSERT INTO app_category(id, description, name) VALUES(1, 'entertainment apps', 'Entertainment'); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(1,true,'com.facebook','Facebook',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(2,true,'com.twitter','Twitter',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(3,true,'com.instagram','Instagram',1); -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Apr 14 05:19:18 2015 From: issues at jboss.org (Dimitrios Kordas (JIRA)) Date: Tue, 14 Apr 2015 05:19:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1942) Duplicate PK encountered when using a ApplyScriptBefore script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058175#comment-13058175 ] Dimitrios Kordas edited comment on ARQ-1942 at 4/14/15 5:19 AM: ---------------------------------------------------------------- I have tested the same issue with JSON/YAML/XML and @UsingDataSet and it still behaves the same way (PK constraints violation) was (Author: sm0ke): I have tested the same issue with JSON/YAML/XML and @UsingDataSet and it still behaves the same way (PK constrains violation) > Duplicate PK encountered when using a ApplyScriptBefore script > -------------------------------------------------------------- > > Key: ARQ-1942 > URL: https://issues.jboss.org/browse/ARQ-1942 > Project: Arquillian > Issue Type: Bug > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6, persistence_1.0.0.Alpha7 > Environment: Windows 8.1 Home, WildFly 8.2.0 Final, jdk1.8.0.40 > Reporter: Dimitrios Kordas > Assignee: Bartosz Majsak > > I am trying to create tests for hibernate under WildFly 8.2.0. > I can successfully create the war using Shrinkwrap, but when Arquillian tries to run the script i provided using the @ApplyScriptBefore annotation hibernate complains about duplicate primary keys even though all keys defined are sequential. > I encounter this error for specific primary keys. For example 1. > If i run the same script (only with an id of 2) multiple times it works. > I have tested the same thing using yaml and json formats and it doesn't work either. > INSERT INTO app_category(id, description, name) VALUES(1, 'entertainment apps', 'Entertainment'); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(1,true,'com.facebook','Facebook',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(2,true,'com.twitter','Twitter',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(3,true,'com.instagram','Instagram',1); -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Apr 14 07:13:19 2015 From: issues at jboss.org (Dimitrios Kordas (JIRA)) Date: Tue, 14 Apr 2015 07:13:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1942) Duplicate PK encountered when using a ApplyScriptBefore script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058758#comment-13058758 ] Dimitrios Kordas commented on ARQ-1942: --------------------------------------- After more testing i have determined the following: Inside the dataset xml i am defining primary keys. These are inserted by persistence with no problem. So if we were to use the above dataset, apps with the ids 2,3,4 would be inserted into the database. Then, inside the test i am creating more apps using jpa/hibernate. If i create only one app, it will take the ID of 1 and no error will occur. If i create more than one apps though, the 2nd will be assigned the ID 2 and it will raise a violation exception since the id2 already exists. So i guess that the dataset script does not update the sequence table in PostgreSQL, and when hibernate starts it doesn't find any entries in the sequence and happilly and obliviously starts at ID 1 causing the problem. Is this a misconfiguration on my part? Can this problem somehow be fixed using configuration for persistence? Thanks for your time, Dimitris > Duplicate PK encountered when using a ApplyScriptBefore script > -------------------------------------------------------------- > > Key: ARQ-1942 > URL: https://issues.jboss.org/browse/ARQ-1942 > Project: Arquillian > Issue Type: Bug > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6, persistence_1.0.0.Alpha7 > Environment: Windows 8.1 Home, WildFly 8.2.0 Final, jdk1.8.0.40 > Reporter: Dimitrios Kordas > Assignee: Bartosz Majsak > > I am trying to create tests for hibernate under WildFly 8.2.0. > I can successfully create the war using Shrinkwrap, but when Arquillian tries to run the script i provided using the @ApplyScriptBefore annotation hibernate complains about duplicate primary keys even though all keys defined are sequential. > I encounter this error for specific primary keys. For example 1. > If i run the same script (only with an id of 2) multiple times it works. > I have tested the same thing using yaml and json formats and it doesn't work either. > INSERT INTO app_category(id, description, name) VALUES(1, 'entertainment apps', 'Entertainment'); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(1,true,'com.facebook','Facebook',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(2,true,'com.twitter','Twitter',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(3,true,'com.instagram','Instagram',1); -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Apr 14 07:14:18 2015 From: issues at jboss.org (Dimitrios Kordas (JIRA)) Date: Tue, 14 Apr 2015 07:14:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1942) Duplicate PK encountered when using a ApplyScriptBefore script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058758#comment-13058758 ] Dimitrios Kordas edited comment on ARQ-1942 at 4/14/15 7:13 AM: ---------------------------------------------------------------- After more testing i have determined the following: Inside the dataset xml i am defining primary keys. These are inserted by persistence with no problem. So if we were to use the above dataset, apps with the ids 2,3,4 would be inserted into the database. Then, inside the test i am creating more apps using jpa/hibernate. If i create only one app, it will take the ID of 1 and no error will occur. If i create more than one apps though, the 2nd will be assigned the ID 2 and it will raise a violation exception since the id2 already exists. So i guess that the dataset script does not update the sequence table in PostgreSQL, and when hibernate starts it doesn't find any entries in the sequence and happilly and obliviously starts at ID 1 causing the problem. If i include no primary keys in the dataset xml, then the problem goes away. Is this a misconfiguration on my part? Can this problem somehow be fixed using configuration for persistence? Thanks for your time, Dimitris was (Author: sm0ke): After more testing i have determined the following: Inside the dataset xml i am defining primary keys. These are inserted by persistence with no problem. So if we were to use the above dataset, apps with the ids 2,3,4 would be inserted into the database. Then, inside the test i am creating more apps using jpa/hibernate. If i create only one app, it will take the ID of 1 and no error will occur. If i create more than one apps though, the 2nd will be assigned the ID 2 and it will raise a violation exception since the id2 already exists. So i guess that the dataset script does not update the sequence table in PostgreSQL, and when hibernate starts it doesn't find any entries in the sequence and happilly and obliviously starts at ID 1 causing the problem. Is this a misconfiguration on my part? Can this problem somehow be fixed using configuration for persistence? Thanks for your time, Dimitris > Duplicate PK encountered when using a ApplyScriptBefore script > -------------------------------------------------------------- > > Key: ARQ-1942 > URL: https://issues.jboss.org/browse/ARQ-1942 > Project: Arquillian > Issue Type: Bug > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6, persistence_1.0.0.Alpha7 > Environment: Windows 8.1 Home, WildFly 8.2.0 Final, jdk1.8.0.40 > Reporter: Dimitrios Kordas > Assignee: Bartosz Majsak > > I am trying to create tests for hibernate under WildFly 8.2.0. > I can successfully create the war using Shrinkwrap, but when Arquillian tries to run the script i provided using the @ApplyScriptBefore annotation hibernate complains about duplicate primary keys even though all keys defined are sequential. > I encounter this error for specific primary keys. For example 1. > If i run the same script (only with an id of 2) multiple times it works. > I have tested the same thing using yaml and json formats and it doesn't work either. > INSERT INTO app_category(id, description, name) VALUES(1, 'entertainment apps', 'Entertainment'); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(1,true,'com.facebook','Facebook',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(2,true,'com.twitter','Twitter',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(3,true,'com.instagram','Instagram',1); -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Apr 14 10:07:19 2015 From: issues at jboss.org (Dimitrios Kordas (JIRA)) Date: Tue, 14 Apr 2015 10:07:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1942) Duplicate PK encountered when using a ApplyScriptBefore script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058850#comment-13058850 ] Dimitrios Kordas commented on ARQ-1942: --------------------------------------- After more close inspection (and closer reading of the docs) i can see that my problem is this: I have not defined a defaultCleanupStrategy strategy, so arquillian defaults to STRICT. I have also not defined a excludeTablesFromCleanup table list with the effect that after the 1st test method (within the same test) the sequences tables and my own tables are being emptied, leading to the errors i have gotten. I have now defined a wildcard excludeTablesFromCleanup setting and a UsingDataSet only on the 1st method and it works. > Duplicate PK encountered when using a ApplyScriptBefore script > -------------------------------------------------------------- > > Key: ARQ-1942 > URL: https://issues.jboss.org/browse/ARQ-1942 > Project: Arquillian > Issue Type: Bug > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6, persistence_1.0.0.Alpha7 > Environment: Windows 8.1 Home, WildFly 8.2.0 Final, jdk1.8.0.40 > Reporter: Dimitrios Kordas > Assignee: Bartosz Majsak > > I am trying to create tests for hibernate under WildFly 8.2.0. > I can successfully create the war using Shrinkwrap, but when Arquillian tries to run the script i provided using the @ApplyScriptBefore annotation hibernate complains about duplicate primary keys even though all keys defined are sequential. > I encounter this error for specific primary keys. For example 1. > If i run the same script (only with an id of 2) multiple times it works. > I have tested the same thing using yaml and json formats and it doesn't work either. > INSERT INTO app_category(id, description, name) VALUES(1, 'entertainment apps', 'Entertainment'); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(1,true,'com.facebook','Facebook',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(2,true,'com.twitter','Twitter',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(3,true,'com.instagram','Instagram',1); -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Apr 15 07:50:18 2015 From: issues at jboss.org (Matous Jobanek (JIRA)) Date: Wed, 15 Apr 2015 07:50:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1937) Class loading issue with injected deployer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059239#comment-13059239 ] Matous Jobanek commented on ARQ-1937: ------------------------------------- Hi, in general, when there is no running deployment the current implementation launches a test method on the client side - no matter if the annotation {{@RunAsClient}} is not declared or the parameter {{testable}} is set to {{true}} \[1\]. So the question might be if this can be allowed at all - something similar to Aslak's suggestion, but more general. I do not see this approach as a good solution - too cruel :-), I believe that some log warning, or changed javadoc could be sufficient - like this one: \[2\]. WDYT? \[1\] https://github.com/arquillian/arquillian-core/blob/master/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/RunModeUtils.java#L50 \[2\] https://github.com/MatousJobanek/arquillian-core/commit/42a2528cb65f540c5b6114deec338a1796f58901 > Class loading issue with injected deployer > ------------------------------------------- > > Key: ARQ-1937 > URL: https://issues.jboss.org/browse/ARQ-1937 > Project: Arquillian > Issue Type: Bug > Components: Deployable Containers SPI > Affects Versions: 1.1.1.Final > Reporter: Martin Gencur > Fix For: 1.1.8.Final > > > Steps to reproduce: > 1) inject a Deployer via @ArquillianResource > 2) declare a deployment as managed=false, use the deployer to deploy artifacts to a managed container > 3) run a test method that operates on the deployment > 4) check that classes inside the test method have the same classloader as the test class itself (see the code below where I call cache.getClass().getClassLoader()) > 5) this does not happen when the deployment is managed=true and deployer API is NOT used. In this case, the classes have a different class loader > In the test below, I tried to load different versions of Infinispan in two deployments and test backward compatibility. However, due to this class loading issue the Infinispan classes are of the latest version regardless of libraries bundled in the WAR. This is probably due to the fact that the Maven test module has the latest Infinispan libraries defined in while the older version is downloaded separately via Maven dependency plugin. > {code} > package com.jboss.datagrid.test.backwardcompatibility; > @RunWith(Arquillian.class) > public class SingleFileStoreBackwardCompatibilityIT { > private DefaultCacheManager dfc; > private String cacheName = "testCache"; > private static final String OLD_ISPN = "dep1_with_old_ispn"; > private static final String NEW_ISPN = "dep2_with_new_ispn"; > private static Map storedMap; > @ArquillianResource > Deployer deployer; > @Deployment(name = OLD_ISPN, testable = true, managed = true, order=1) > @TargetsContainer("container1") > public static WebArchive createDeploymentOld() { > WebArchive jar = DeploymentBuilder.createTestArchiveWithPreviousJDG("test1.war", "previous"); > System.out.println("ClassLoader: " + SingleFileStoreBackwardCompatibilityIT.class.getClassLoader()); > return jar; > } > @Deployment(name = NEW_ISPN, testable = true, managed = true, order=2) > @TargetsContainer("container2") > public static WebArchive createDeploymentNew() { > WebArchive jar = DeploymentBuilder.createTestArchive("test2.war", "current"); > return jar; > } > private DefaultCacheManager configureCacheManager(boolean clearCacheStore) throws Exception { > GlobalConfiguration glob = new GlobalConfigurationBuilder().nonClusteredDefault() > .globalJmxStatistics().allowDuplicateDomains(true). > build(); > ConfigurationBuilder c = new ConfigurationBuilder(); > c.clustering().cacheMode(CacheMode.LOCAL); > File tmpStore = new File("/tmp/cache/" + cacheName + ".dat"); > if (clearCacheStore && tmpStore.exists()) { > tmpStore.delete(); > } > c.persistence().passivation(false).addSingleFileStore().purgeOnStartup(false).location("/tmp/cache/"); > Configuration cnf = c.build(); > DefaultCacheManager manager = new DefaultCacheManager(glob); > manager.defineConfiguration(cacheName, cnf); > return manager; > } > @Test > @OperateOnDeployment(OLD_ISPN) > @InSequence(1) > public void testStoreWithOldJDG() throws Exception { > deployer.deploy(OLD_ISPN); > dfc = configureCacheManager(true); > dfc.start(); > Cache cache = dfc.getCache(cacheName); > System.out.println("Version: " + cache.getVersion()); > System.out.println("ClassLoader: " + cache.getClass().getClassLoader()); > storedMap = new HashMap(); > storedMap.put("k", "v"); > cache.put("mapKey", storedMap); > dfc.stop(); > deployer.undeploy(OLD_ISPN); > } > @Test > @OperateOnDeployment(NEW_ISPN) > @InSequence(2) > public void testReadWithNewJDG() throws Exception { > deployer.deploy(NEW_ISPN); > dfc = configureCacheManager(false); > dfc.start(); > Cache cache = dfc.getCache(cacheName); > System.out.println("ClassLoader: " + cache.getClass().getClassLoader()); > System.out.println("Version: " + cache.getVersion()); > assertEquals(storedMap, cache.get("mapKey")); > dfc.stop(); > deployer.undeploy(NEW_ISPN); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Apr 15 12:09:19 2015 From: issues at jboss.org (Bartosz Majsak (JIRA)) Date: Wed, 15 Apr 2015 12:09:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1942) Duplicate PK encountered when using a ApplyScriptBefore script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059418#comment-13059418 ] Bartosz Majsak commented on ARQ-1942: ------------------------------------- Thanks for a detailed report. I am on holidays now so cannot really dive into this, but I will be back first weekend of May and this is one of the first things for me to look at. Cheers, Bartosz > Duplicate PK encountered when using a ApplyScriptBefore script > -------------------------------------------------------------- > > Key: ARQ-1942 > URL: https://issues.jboss.org/browse/ARQ-1942 > Project: Arquillian > Issue Type: Bug > Components: Extension - Persistence > Affects Versions: persistence_1.0.0.Alpha6, persistence_1.0.0.Alpha7 > Environment: Windows 8.1 Home, WildFly 8.2.0 Final, jdk1.8.0.40 > Reporter: Dimitrios Kordas > Assignee: Bartosz Majsak > > I am trying to create tests for hibernate under WildFly 8.2.0. > I can successfully create the war using Shrinkwrap, but when Arquillian tries to run the script i provided using the @ApplyScriptBefore annotation hibernate complains about duplicate primary keys even though all keys defined are sequential. > I encounter this error for specific primary keys. For example 1. > If i run the same script (only with an id of 2) multiple times it works. > I have tested the same thing using yaml and json formats and it doesn't work either. > INSERT INTO app_category(id, description, name) VALUES(1, 'entertainment apps', 'Entertainment'); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(1,true,'com.facebook','Facebook',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(2,true,'com.twitter','Twitter',1); > INSERT INTO app(id,active,fqn,name,app_category_id) VALUES(3,true,'com.instagram','Instagram',1); -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Apr 16 19:00:21 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Thu, 16 Apr 2015 19:00:21 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails because of duplicate CDI beans when beans inside a dependent JAR. In-Reply-To: References: Message-ID: Chris Rankin created ARQ-1943: --------------------------------- Summary: Deployment fails because of duplicate CDI beans when beans inside a dependent JAR. Key: ARQ-1943 URL: https://issues.jboss.org/browse/ARQ-1943 Project: Arquillian Issue Type: Bug Components: Tomcat Containers Affects Versions: tomcat_1.0.0.CR7 Environment: Windows 7 x64, Linux x64, JDK7 Reporter: Chris Rankin Attachments: arquillian-test.tar.xz Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: - a @Dependent bean with a @Produces method - a META-INF/beans.xml file. When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: SEVERE: Servlet threw load() exception org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) Possible dependencies: - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Thu Apr 16 19:00:22 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Thu, 16 Apr 2015 19:00:22 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails because of duplicate CDI beans when beans inside a dependent JAR. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Rankin updated ARQ-1943: ------------------------------ Attachment: arquillian-test.tar.xz Example project. > Deployment fails because of duplicate CDI beans when beans inside a dependent JAR. > ---------------------------------------------------------------------------------- > > Key: ARQ-1943 > URL: https://issues.jboss.org/browse/ARQ-1943 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Environment: Windows 7 x64, Linux x64, JDK7 > Reporter: Chris Rankin > Attachments: arquillian-test.tar.xz > > > Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: > I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: > - a @Dependent bean with a @Produces method > - a META-INF/beans.xml file. > When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: > SEVERE: Servlet threw load() exception > org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble > at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble > at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) > Possible dependencies: > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Apr 17 03:42:18 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 17 Apr 2015 03:42:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1927) Make use of TCCL in ARQ ManagedContainer configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1927: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done pushed upstream https://github.com/arquillian/arquillian-core/commit/80d481bb0c0999b0c815a4c55b0e420682db4b6d & https://github.com/arquillian/arquillian-core/commit/d1f223a10bf8b0f89ae2875abd2b6719b8109b17 > Make use of TCCL in ARQ ManagedContainer configurable > ----------------------------------------------------- > > Key: ARQ-1927 > URL: https://issues.jboss.org/browse/ARQ-1927 > Project: Arquillian > Issue Type: Feature Request > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Fix For: 1.1.8.Final > > > In WildFly it is considerred intended behaviour that test code gets called with the TCCL set to the test deployment. IMHO this shadows potential problems when the functionality under test is not called from an ARQ test case (i.e. from an normal javaee endpoint) > For Camel integration this behaviour is not acceptable. > CrossLink: https://github.com/wildfly-extras/wildfly-camel/issues/340 -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Apr 17 03:52:33 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 17 Apr 2015 03:52:33 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-567) Supporting Test Suites (@ArquillianSuite) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-567: ------------------------------ Fix Version/s: 1.2.0.Alpha1 (was: 1.1.8.Final) > Supporting Test Suites (@ArquillianSuite) > ----------------------------------------- > > Key: ARQ-567 > URL: https://issues.jboss.org/browse/ARQ-567 > Project: Arquillian > Issue Type: Feature Request > Reporter: Mousavi Jahan Abadi S. M. > Assignee: Aslak Knutsen > Fix For: 1.2.0.Alpha1 > > > Currently, it is supported that JUnit test cases being run by Arquillian. This feature request is request for supporting test suites too to be run by Arquillian too. Idea is like: > @RunWith(ArquillianSuite.class) > @Suite.SuiteClasses( { TestCase1.class, TestCase2.class, .... } ) > public class AllTests{ > @Deployment > public static JavaArchive createTestArchive(){ > return ShrinkWrap.create(JavaArchive.class,"test.jar"); > } > } > The advantages of above approach for users of Arquillian framework are: > - Test cases don't needed to be modified to have: "@RunWith(Arquillian.class)" annotation. In other words, test cases will be pure JUnit code, and no Arquillian code (results in less coding for end users). > - It is not necessary to include the static "@Deployment" methods in all test cases any more, and only Test Suite need to define the archieving/deployment related setting/definitions. > The advantage of above approach for framework itself is: > - From performance point-of-view, it becomes possible for Arquillian to deploy all test cases in the Test Suite into J2EE container in one action (one deploy/undeploy for one test suite, instead of mulitple deploy/undeploy for each test case). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Apr 17 03:52:34 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 17 Apr 2015 03:52:34 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1937) Class loading issue with injected deployer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1937: ------------------------------- Fix Version/s: 1.2.0.Alpha1 (was: 1.1.8.Final) > Class loading issue with injected deployer > ------------------------------------------- > > Key: ARQ-1937 > URL: https://issues.jboss.org/browse/ARQ-1937 > Project: Arquillian > Issue Type: Bug > Components: Deployable Containers SPI > Affects Versions: 1.1.1.Final > Reporter: Martin Gencur > Fix For: 1.2.0.Alpha1 > > > Steps to reproduce: > 1) inject a Deployer via @ArquillianResource > 2) declare a deployment as managed=false, use the deployer to deploy artifacts to a managed container > 3) run a test method that operates on the deployment > 4) check that classes inside the test method have the same classloader as the test class itself (see the code below where I call cache.getClass().getClassLoader()) > 5) this does not happen when the deployment is managed=true and deployer API is NOT used. In this case, the classes have a different class loader > In the test below, I tried to load different versions of Infinispan in two deployments and test backward compatibility. However, due to this class loading issue the Infinispan classes are of the latest version regardless of libraries bundled in the WAR. This is probably due to the fact that the Maven test module has the latest Infinispan libraries defined in while the older version is downloaded separately via Maven dependency plugin. > {code} > package com.jboss.datagrid.test.backwardcompatibility; > @RunWith(Arquillian.class) > public class SingleFileStoreBackwardCompatibilityIT { > private DefaultCacheManager dfc; > private String cacheName = "testCache"; > private static final String OLD_ISPN = "dep1_with_old_ispn"; > private static final String NEW_ISPN = "dep2_with_new_ispn"; > private static Map storedMap; > @ArquillianResource > Deployer deployer; > @Deployment(name = OLD_ISPN, testable = true, managed = true, order=1) > @TargetsContainer("container1") > public static WebArchive createDeploymentOld() { > WebArchive jar = DeploymentBuilder.createTestArchiveWithPreviousJDG("test1.war", "previous"); > System.out.println("ClassLoader: " + SingleFileStoreBackwardCompatibilityIT.class.getClassLoader()); > return jar; > } > @Deployment(name = NEW_ISPN, testable = true, managed = true, order=2) > @TargetsContainer("container2") > public static WebArchive createDeploymentNew() { > WebArchive jar = DeploymentBuilder.createTestArchive("test2.war", "current"); > return jar; > } > private DefaultCacheManager configureCacheManager(boolean clearCacheStore) throws Exception { > GlobalConfiguration glob = new GlobalConfigurationBuilder().nonClusteredDefault() > .globalJmxStatistics().allowDuplicateDomains(true). > build(); > ConfigurationBuilder c = new ConfigurationBuilder(); > c.clustering().cacheMode(CacheMode.LOCAL); > File tmpStore = new File("/tmp/cache/" + cacheName + ".dat"); > if (clearCacheStore && tmpStore.exists()) { > tmpStore.delete(); > } > c.persistence().passivation(false).addSingleFileStore().purgeOnStartup(false).location("/tmp/cache/"); > Configuration cnf = c.build(); > DefaultCacheManager manager = new DefaultCacheManager(glob); > manager.defineConfiguration(cacheName, cnf); > return manager; > } > @Test > @OperateOnDeployment(OLD_ISPN) > @InSequence(1) > public void testStoreWithOldJDG() throws Exception { > deployer.deploy(OLD_ISPN); > dfc = configureCacheManager(true); > dfc.start(); > Cache cache = dfc.getCache(cacheName); > System.out.println("Version: " + cache.getVersion()); > System.out.println("ClassLoader: " + cache.getClass().getClassLoader()); > storedMap = new HashMap(); > storedMap.put("k", "v"); > cache.put("mapKey", storedMap); > dfc.stop(); > deployer.undeploy(OLD_ISPN); > } > @Test > @OperateOnDeployment(NEW_ISPN) > @InSequence(2) > public void testReadWithNewJDG() throws Exception { > deployer.deploy(NEW_ISPN); > dfc = configureCacheManager(false); > dfc.start(); > Cache cache = dfc.getCache(cacheName); > System.out.println("ClassLoader: " + cache.getClass().getClassLoader()); > System.out.println("Version: " + cache.getVersion()); > assertEquals(storedMap, cache.get("mapKey")); > dfc.stop(); > deployer.undeploy(NEW_ISPN); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Apr 17 03:52:34 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 17 Apr 2015 03:52:34 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-472) Metadata annotations should not be read directly from the Java Classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-472: ------------------------------ Fix Version/s: 1.2.0.Alpha1 (was: 1.1.8.Final) > Metadata annotations should not be read directly from the Java Classes > ---------------------------------------------------------------------- > > Key: ARQ-472 > URL: https://issues.jboss.org/browse/ARQ-472 > Project: Arquillian > Issue Type: Feature Request > Components: Base Implementation > Affects Versions: 1.0.0.Final > Reporter: Aslak Knutsen > Fix For: 1.2.0.Alpha1 > > > To better support Alternative languages on the JVM we should move away from reading MetaData annotations directly from the Java Classes, instead create a MetaModel indirection that is replaceable and can be implemented to fit specific needs. > This goes for Metadata Annotations like @RunAsClient, @OperatesOnDeployment, @OperatesOnContainer, @Deployment etc -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Apr 17 04:34:23 2015 From: issues at jboss.org (Andy K (JIRA)) Date: Fri, 17 Apr 2015 04:34:23 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-567) Supporting Test Suites (@ArquillianSuite) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy K updated ARQ-567: ----------------------- ECCLESIA Clerk Server: Ibis ----------------------------------------------------------------------- Andreas Kind Sehr geehrte Damen und Herren, ich bin bis zum 19.04.2015 einschlie?lich nicht erreichbar. Ihre E-Mail wird bis dahin archiviert. Mit freundlichen Gr??en, > Supporting Test Suites (@ArquillianSuite) > ----------------------------------------- > > Key: ARQ-567 > URL: https://issues.jboss.org/browse/ARQ-567 > Project: Arquillian > Issue Type: Feature Request > Reporter: Mousavi Jahan Abadi S. M. > Assignee: Aslak Knutsen > Fix For: 1.2.0.Alpha1 > > > Currently, it is supported that JUnit test cases being run by Arquillian. This feature request is request for supporting test suites too to be run by Arquillian too. Idea is like: > @RunWith(ArquillianSuite.class) > @Suite.SuiteClasses( { TestCase1.class, TestCase2.class, .... } ) > public class AllTests{ > @Deployment > public static JavaArchive createTestArchive(){ > return ShrinkWrap.create(JavaArchive.class,"test.jar"); > } > } > The advantages of above approach for users of Arquillian framework are: > - Test cases don't needed to be modified to have: "@RunWith(Arquillian.class)" annotation. In other words, test cases will be pure JUnit code, and no Arquillian code (results in less coding for end users). > - It is not necessary to include the static "@Deployment" methods in all test cases any more, and only Test Suite need to define the archieving/deployment related setting/definitions. > The advantage of above approach for framework itself is: > - From performance point-of-view, it becomes possible for Arquillian to deploy all test cases in the Test Suite into J2EE container in one action (one deploy/undeploy for one test suite, instead of mulitple deploy/undeploy for each test case). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Apr 17 15:54:31 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Fri, 17 Apr 2015 15:54:31 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-567) Supporting Test Suites (@ArquillianSuite) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-567: ------------------------------ Comment: was deleted (was: ECCLESIA Clerk Server: Ibis ----------------------------------------------------------------------- Andreas Kind Sehr geehrte Damen und Herren, ich bin bis zum 19.04.2015 einschlie?lich nicht erreichbar. Ihre E-Mail wird bis dahin archiviert. Mit freundlichen Gr??en, ) > Supporting Test Suites (@ArquillianSuite) > ----------------------------------------- > > Key: ARQ-567 > URL: https://issues.jboss.org/browse/ARQ-567 > Project: Arquillian > Issue Type: Feature Request > Reporter: Mousavi Jahan Abadi S. M. > Assignee: Aslak Knutsen > Fix For: 1.2.0.Alpha1 > > > Currently, it is supported that JUnit test cases being run by Arquillian. This feature request is request for supporting test suites too to be run by Arquillian too. Idea is like: > @RunWith(ArquillianSuite.class) > @Suite.SuiteClasses( { TestCase1.class, TestCase2.class, .... } ) > public class AllTests{ > @Deployment > public static JavaArchive createTestArchive(){ > return ShrinkWrap.create(JavaArchive.class,"test.jar"); > } > } > The advantages of above approach for users of Arquillian framework are: > - Test cases don't needed to be modified to have: "@RunWith(Arquillian.class)" annotation. In other words, test cases will be pure JUnit code, and no Arquillian code (results in less coding for end users). > - It is not necessary to include the static "@Deployment" methods in all test cases any more, and only Test Suite need to define the archieving/deployment related setting/definitions. > The advantage of above approach for framework itself is: > - From performance point-of-view, it becomes possible for Arquillian to deploy all test cases in the Test Suite into J2EE container in one action (one deploy/undeploy for one test suite, instead of mulitple deploy/undeploy for each test case). -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sat Apr 18 19:07:18 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Sat, 18 Apr 2015 19:07:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when beans inside a dependent JAR. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Rankin updated ARQ-1943: ------------------------------ Summary: Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when beans inside a dependent JAR. (was: Deployment fails because of duplicate CDI beans when beans inside a dependent JAR.) > Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when beans inside a dependent JAR. > ----------------------------------------------------------------------------------------------------------- > > Key: ARQ-1943 > URL: https://issues.jboss.org/browse/ARQ-1943 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Environment: Windows 7 x64, Linux x64, JDK7 > Reporter: Chris Rankin > Attachments: arquillian-test.tar.xz > > > Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: > I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: > - a @Dependent bean with a @Produces method > - a META-INF/beans.xml file. > When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: > SEVERE: Servlet threw load() exception > org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble > at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble > at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) > Possible dependencies: > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sat Apr 18 19:15:21 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Sat, 18 Apr 2015 19:15:21 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when beans inside a dependent JAR. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060396#comment-13060396 ] Chris Rankin commented on ARQ-1943: ----------------------------------- I've been experimenting with the versions of various dependencies inside my example project, and I have discovered that it works fine with WELD <= 2.2.4.Final: {code} SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/home/chris/.m2/repository/ch/qos/logback/logback-classic/1.0.13/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/chris/Programs/omnifone/arquillian-test/test-servlet/target/tomcat7-embedded/webapps/ROOT/WEB-INF/lib/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder] 00:05:43.774 localhost-startStop-1 INFO o.j.w.e.s.EnhancedListener - Initialize Weld using ServletContainerInitializer 00:05:43.795 localhost-startStop-1 INFO org.jboss.weld.Version - WELD-000900: 2.2.4 (Final) 00:05:43.962 localhost-startStop-1 INFO org.jboss.weld.Bootstrap - WELD-000101: Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously. 00:05:44.085 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PostActivate not found, interception based on it is not enabled 00:05:44.086 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PrePassivate not found, interception based on it is not enabled 00:05:44.291 localhost-startStop-1 INFO o.j.w.e.tomcat.TomcatContainer - Tomcat 7+ detected, CDI injection will be available in Servlets, Filters and Listeners. 00:05:44.437 localhost-startStop-1 INFO o.j.w.e.servlet.Listener - org.jboss.weld.environment.servlet.EnhancedListener used for ServletContext notifications 00:05:44.437 localhost-startStop-1 INFO o.j.w.e.s.EnhancedListener - org.jboss.weld.environment.servlet.Listener used for ServletRequest and HttpSession notifications Apr 19, 2015 12:05:44 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deployment of web application archive /home/chris/Programs/omnifone/arquillian-test/test-servlet/target/tomcat7-embedded/webapps/ROOT.war has finished in 1,582 ms 00:05:45.964 http-bio-8084-exec-9 INFO org.testing.web.TroubleServlet - Look: Here comes trouble! event: org.jboss.arquillian.container.spi.event.container.BeforeStop at 51a42578 d: _DEFAULT_ {code} The problem appears with WELD >= 2.2.5.Final: {code} SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/home/chris/.m2/repository/ch/qos/logback/logback-classic/1.0.13/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/chris/Programs/omnifone/arquillian-test/test-servlet/target/tomcat7-embedded/webapps/ROOT/WEB-INF/lib/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder] 00:10:14.508 localhost-startStop-1 INFO o.j.w.e.servletWeldServlet - WELD-ENV-001008: Initialize Weld using ServletContainerInitializer 00:10:14.521 localhost-startStop-1 INFO org.jboss.weld.Version - WELD-000900: 2.2.5 (Final) 00:10:14.537 localhost-startStop-1 INFO org.jboss.weld.Bootstrap - WELD-ENV-000020: Using jandex for bean discovery 00:10:14.613 localhost-startStop-1 WARN o.j.w.e.servletWeldServlet - WELD-ENV-001004: Found both WEB-INF/beans.xml and WEB-INF/classes/META-INF/beans.xml. It's not portable to use both locations at the same time. Weld is going to use jndi:/localhost/WEB-INF/beans.xml. 00:10:14.709 localhost-startStop-1 INFO org.jboss.weld.Bootstrap - WELD-000101: Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously. 00:10:14.799 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PostActivate not found, interception based on it is not enabled 00:10:14.800 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PrePassivate not found, interception based on it is not enabled 00:10:14.951 localhost-startStop-1 INFO o.j.w.e.servletTomcat - WELD-ENV-001100: Tomcat 7+ detected, CDI injection will be available in Servlets, Filters and Listeners. 00:10:15.096 localhost-startStop-1 INFO o.j.w.e.servletWeldServlet - WELD-ENV-001006: org.jboss.weld.environment.servlet.EnhancedListener used for ServletContext notifications 00:10:15.096 localhost-startStop-1 INFO o.j.w.e.servletWeldServlet - WELD-ENV-001009: org.jboss.weld.environment.servlet.Listener used for ServletRequest and HttpSession notifications Apr 19, 2015 12:10:15 AM org.apache.catalina.core.ApplicationContext log INFO: Marking servlet Trouble as unavailable Apr 19, 2015 12:10:15 AM org.apache.catalina.core.StandardContext loadOnStartup SEVERE: Servlet threw load() exception org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) Possible dependencies: - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] {code} However, I must stress that Maven's WAR artifact deploys fine with WELD 2.2.5.Final inside Tomcat 7.0.52. It is only the Arquillian deployment which begins to fail. > Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when beans inside a dependent JAR. > ----------------------------------------------------------------------------------------------------------- > > Key: ARQ-1943 > URL: https://issues.jboss.org/browse/ARQ-1943 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Environment: Windows 7 x64, Linux x64, JDK7 > Reporter: Chris Rankin > Attachments: arquillian-test.tar.xz > > > Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: > I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: > - a @Dependent bean with a @Produces method > - a META-INF/beans.xml file. > When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: > SEVERE: Servlet threw load() exception > org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble > at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble > at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) > Possible dependencies: > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sat Apr 18 19:16:18 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Sat, 18 Apr 2015 19:16:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when beans inside a dependent JAR. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060396#comment-13060396 ] Chris Rankin edited comment on ARQ-1943 at 4/18/15 7:15 PM: ------------------------------------------------------------ I've been experimenting with the versions of various dependencies inside my example project, and I have discovered that Arquillian works fine with WELD <= 2.2.4.Final: {code} SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/home/chris/.m2/repository/ch/qos/logback/logback-classic/1.0.13/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/chris/Programs/omnifone/arquillian-test/test-servlet/target/tomcat7-embedded/webapps/ROOT/WEB-INF/lib/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder] 00:05:43.774 localhost-startStop-1 INFO o.j.w.e.s.EnhancedListener - Initialize Weld using ServletContainerInitializer 00:05:43.795 localhost-startStop-1 INFO org.jboss.weld.Version - WELD-000900: 2.2.4 (Final) 00:05:43.962 localhost-startStop-1 INFO org.jboss.weld.Bootstrap - WELD-000101: Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously. 00:05:44.085 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PostActivate not found, interception based on it is not enabled 00:05:44.086 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PrePassivate not found, interception based on it is not enabled 00:05:44.291 localhost-startStop-1 INFO o.j.w.e.tomcat.TomcatContainer - Tomcat 7+ detected, CDI injection will be available in Servlets, Filters and Listeners. 00:05:44.437 localhost-startStop-1 INFO o.j.w.e.servlet.Listener - org.jboss.weld.environment.servlet.EnhancedListener used for ServletContext notifications 00:05:44.437 localhost-startStop-1 INFO o.j.w.e.s.EnhancedListener - org.jboss.weld.environment.servlet.Listener used for ServletRequest and HttpSession notifications Apr 19, 2015 12:05:44 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deployment of web application archive /home/chris/Programs/omnifone/arquillian-test/test-servlet/target/tomcat7-embedded/webapps/ROOT.war has finished in 1,582 ms 00:05:45.964 http-bio-8084-exec-9 INFO org.testing.web.TroubleServlet - Look: Here comes trouble! event: org.jboss.arquillian.container.spi.event.container.BeforeStop at 51a42578 d: _DEFAULT_ {code} The problem appears with WELD >= 2.2.5.Final: {code} SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/home/chris/.m2/repository/ch/qos/logback/logback-classic/1.0.13/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/chris/Programs/omnifone/arquillian-test/test-servlet/target/tomcat7-embedded/webapps/ROOT/WEB-INF/lib/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder] 00:10:14.508 localhost-startStop-1 INFO o.j.w.e.servletWeldServlet - WELD-ENV-001008: Initialize Weld using ServletContainerInitializer 00:10:14.521 localhost-startStop-1 INFO org.jboss.weld.Version - WELD-000900: 2.2.5 (Final) 00:10:14.537 localhost-startStop-1 INFO org.jboss.weld.Bootstrap - WELD-ENV-000020: Using jandex for bean discovery 00:10:14.613 localhost-startStop-1 WARN o.j.w.e.servletWeldServlet - WELD-ENV-001004: Found both WEB-INF/beans.xml and WEB-INF/classes/META-INF/beans.xml. It's not portable to use both locations at the same time. Weld is going to use jndi:/localhost/WEB-INF/beans.xml. 00:10:14.709 localhost-startStop-1 INFO org.jboss.weld.Bootstrap - WELD-000101: Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously. 00:10:14.799 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PostActivate not found, interception based on it is not enabled 00:10:14.800 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PrePassivate not found, interception based on it is not enabled 00:10:14.951 localhost-startStop-1 INFO o.j.w.e.servletTomcat - WELD-ENV-001100: Tomcat 7+ detected, CDI injection will be available in Servlets, Filters and Listeners. 00:10:15.096 localhost-startStop-1 INFO o.j.w.e.servletWeldServlet - WELD-ENV-001006: org.jboss.weld.environment.servlet.EnhancedListener used for ServletContext notifications 00:10:15.096 localhost-startStop-1 INFO o.j.w.e.servletWeldServlet - WELD-ENV-001009: org.jboss.weld.environment.servlet.Listener used for ServletRequest and HttpSession notifications Apr 19, 2015 12:10:15 AM org.apache.catalina.core.ApplicationContext log INFO: Marking servlet Trouble as unavailable Apr 19, 2015 12:10:15 AM org.apache.catalina.core.StandardContext loadOnStartup SEVERE: Servlet threw load() exception org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) Possible dependencies: - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] {code} However, I must stress that Maven's WAR artifact deploys fine with WELD 2.2.5.Final inside Tomcat 7.0.52. It is only the Arquillian deployment which begins to fail. was (Author: chrisjr): I've been experimenting with the versions of various dependencies inside my example project, and I have discovered that it works fine with WELD <= 2.2.4.Final: {code} SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/home/chris/.m2/repository/ch/qos/logback/logback-classic/1.0.13/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/chris/Programs/omnifone/arquillian-test/test-servlet/target/tomcat7-embedded/webapps/ROOT/WEB-INF/lib/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder] 00:05:43.774 localhost-startStop-1 INFO o.j.w.e.s.EnhancedListener - Initialize Weld using ServletContainerInitializer 00:05:43.795 localhost-startStop-1 INFO org.jboss.weld.Version - WELD-000900: 2.2.4 (Final) 00:05:43.962 localhost-startStop-1 INFO org.jboss.weld.Bootstrap - WELD-000101: Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously. 00:05:44.085 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PostActivate not found, interception based on it is not enabled 00:05:44.086 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PrePassivate not found, interception based on it is not enabled 00:05:44.291 localhost-startStop-1 INFO o.j.w.e.tomcat.TomcatContainer - Tomcat 7+ detected, CDI injection will be available in Servlets, Filters and Listeners. 00:05:44.437 localhost-startStop-1 INFO o.j.w.e.servlet.Listener - org.jboss.weld.environment.servlet.EnhancedListener used for ServletContext notifications 00:05:44.437 localhost-startStop-1 INFO o.j.w.e.s.EnhancedListener - org.jboss.weld.environment.servlet.Listener used for ServletRequest and HttpSession notifications Apr 19, 2015 12:05:44 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deployment of web application archive /home/chris/Programs/omnifone/arquillian-test/test-servlet/target/tomcat7-embedded/webapps/ROOT.war has finished in 1,582 ms 00:05:45.964 http-bio-8084-exec-9 INFO org.testing.web.TroubleServlet - Look: Here comes trouble! event: org.jboss.arquillian.container.spi.event.container.BeforeStop at 51a42578 d: _DEFAULT_ {code} The problem appears with WELD >= 2.2.5.Final: {code} SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/home/chris/.m2/repository/ch/qos/logback/logback-classic/1.0.13/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/chris/Programs/omnifone/arquillian-test/test-servlet/target/tomcat7-embedded/webapps/ROOT/WEB-INF/lib/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder] 00:10:14.508 localhost-startStop-1 INFO o.j.w.e.servletWeldServlet - WELD-ENV-001008: Initialize Weld using ServletContainerInitializer 00:10:14.521 localhost-startStop-1 INFO org.jboss.weld.Version - WELD-000900: 2.2.5 (Final) 00:10:14.537 localhost-startStop-1 INFO org.jboss.weld.Bootstrap - WELD-ENV-000020: Using jandex for bean discovery 00:10:14.613 localhost-startStop-1 WARN o.j.w.e.servletWeldServlet - WELD-ENV-001004: Found both WEB-INF/beans.xml and WEB-INF/classes/META-INF/beans.xml. It's not portable to use both locations at the same time. Weld is going to use jndi:/localhost/WEB-INF/beans.xml. 00:10:14.709 localhost-startStop-1 INFO org.jboss.weld.Bootstrap - WELD-000101: Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously. 00:10:14.799 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PostActivate not found, interception based on it is not enabled 00:10:14.800 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PrePassivate not found, interception based on it is not enabled 00:10:14.951 localhost-startStop-1 INFO o.j.w.e.servletTomcat - WELD-ENV-001100: Tomcat 7+ detected, CDI injection will be available in Servlets, Filters and Listeners. 00:10:15.096 localhost-startStop-1 INFO o.j.w.e.servletWeldServlet - WELD-ENV-001006: org.jboss.weld.environment.servlet.EnhancedListener used for ServletContext notifications 00:10:15.096 localhost-startStop-1 INFO o.j.w.e.servletWeldServlet - WELD-ENV-001009: org.jboss.weld.environment.servlet.Listener used for ServletRequest and HttpSession notifications Apr 19, 2015 12:10:15 AM org.apache.catalina.core.ApplicationContext log INFO: Marking servlet Trouble as unavailable Apr 19, 2015 12:10:15 AM org.apache.catalina.core.StandardContext loadOnStartup SEVERE: Servlet threw load() exception org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) Possible dependencies: - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] {code} However, I must stress that Maven's WAR artifact deploys fine with WELD 2.2.5.Final inside Tomcat 7.0.52. It is only the Arquillian deployment which begins to fail. > Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when beans inside a dependent JAR. > ----------------------------------------------------------------------------------------------------------- > > Key: ARQ-1943 > URL: https://issues.jboss.org/browse/ARQ-1943 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Environment: Windows 7 x64, Linux x64, JDK7 > Reporter: Chris Rankin > Attachments: arquillian-test.tar.xz > > > Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: > I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: > - a @Dependent bean with a @Produces method > - a META-INF/beans.xml file. > When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: > SEVERE: Servlet threw load() exception > org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble > at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble > at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) > Possible dependencies: > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sat Apr 18 19:46:18 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Sat, 18 Apr 2015 19:46:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when beans inside a dependent JAR. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060397#comment-13060397 ] Chris Rankin commented on ARQ-1943: ----------------------------------- Could this be related to WELD-1658? > Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when beans inside a dependent JAR. > ----------------------------------------------------------------------------------------------------------- > > Key: ARQ-1943 > URL: https://issues.jboss.org/browse/ARQ-1943 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Environment: Windows 7 x64, Linux x64, JDK7 > Reporter: Chris Rankin > Attachments: arquillian-test.tar.xz > > > Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: > I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: > - a @Dependent bean with a @Produces method > - a META-INF/beans.xml file. > When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: > SEVERE: Servlet threw load() exception > org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble > at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble > at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) > Possible dependencies: > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Apr 19 09:30:18 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Sun, 19 Apr 2015 09:30:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Rankin updated ARQ-1943: ------------------------------ Summary: Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive (was: Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when beans inside a dependent JAR.) > Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive > -------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1943 > URL: https://issues.jboss.org/browse/ARQ-1943 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Environment: Windows 7 x64, Linux x64, JDK7 > Reporter: Chris Rankin > Attachments: arquillian-test.tar.xz > > > Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: > I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: > - a @Dependent bean with a @Produces method > - a META-INF/beans.xml file. > When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: > SEVERE: Servlet threw load() exception > org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble > at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble > at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) > Possible dependencies: > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Apr 19 09:37:18 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Sun, 19 Apr 2015 09:37:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Rankin updated ARQ-1943: ------------------------------ Attachment: arquillian-test.tar.xz I've updated my sample project: - Arquillian 1.1.8.Final - WELD 2.2.10.SP1 - Removed the "suite" extenstion (seeing as there's only one test anyway). This sample project demonstrates the same error as the original. > Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive > -------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1943 > URL: https://issues.jboss.org/browse/ARQ-1943 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Environment: Windows 7 x64, Linux x64, JDK7 > Reporter: Chris Rankin > Attachments: arquillian-test.tar.xz, arquillian-test.tar.xz > > > Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: > I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: > - a @Dependent bean with a @Produces method > - a META-INF/beans.xml file. > When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: > SEVERE: Servlet threw load() exception > org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble > at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble > at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) > Possible dependencies: > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Apr 19 18:26:18 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Sun, 19 Apr 2015 18:26:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1944) Linkage error with arquillian-junit.jar In-Reply-To: References: Message-ID: Chris Rankin created ARQ-1944: --------------------------------- Summary: Linkage error with arquillian-junit.jar Key: ARQ-1944 URL: https://issues.jboss.org/browse/ARQ-1944 Project: Arquillian Issue Type: Bug Affects Versions: 1.1.8.Final, 1.1.7.Final Environment: JDK7, Windows 7 x64, Linux x64 Reporter: Chris Rankin Testing a WAR in embedded Tomcat >= 7.0.50 using Restassured, JUnit and Hamcrest matchers. (TestNG works fine). The test fails with this error message: {code}Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.404 sec <<< FAILURE! - in org.testing.web.TroubleIT testTrouble(org.testing.web.TroubleIT) Time elapsed: 0.774 sec <<< ERROR! java.lang.LinkageError: loader constraint violation: when resolving interface method "com.jayway.restassured.specification.ResponseSpecification.statusCode(Lorg/hamcrest/Matcher;)Lcom/jayway/restassured/specification/ResponseSpecification;" the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the current class, org/testing/web/TroubleIT, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for resolved class, com/jayway/restassured/specification/ResponseSpecification, have different Class objects for the type cification.statusCode(Lorg/hamcrest/Matcher;)Lcom/jayway/restassured/specification/ResponseSpecification; used in the signature at org.testing.web.TroubleIT.testTrouble(TroubleIT.java:35) {code} This error can be resolved in three different ways: - Rewrite the test using TestNG - Rewrite the test without using any Hamcrest matchers. - Remove "org.hamcrest" from {{org.jboss.arquillian.junit.container.JUnitDeploymentAppender}}. See [Issue #78 for arquillian-core|https://github.com/arquillian/arquillian-core/issues/78] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Sun Apr 19 18:29:18 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Sun, 19 Apr 2015 18:29:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1944) Linkage error with arquillian-junit.jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Rankin updated ARQ-1944: ------------------------------ Attachment: arquillian-hamcrest-test.tar.xz Simple example Maven project. > Linkage error with arquillian-junit.jar > --------------------------------------- > > Key: ARQ-1944 > URL: https://issues.jboss.org/browse/ARQ-1944 > Project: Arquillian > Issue Type: Bug > Affects Versions: 1.1.7.Final, 1.1.8.Final > Environment: JDK7, Windows 7 x64, Linux x64 > Reporter: Chris Rankin > Attachments: arquillian-hamcrest-test.tar.xz > > > Testing a WAR in embedded Tomcat >= 7.0.50 using Restassured, JUnit and Hamcrest matchers. (TestNG works fine). > The test fails with this error message: > {code}Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.404 sec <<< FAILURE! - in org.testing.web.TroubleIT > testTrouble(org.testing.web.TroubleIT) Time elapsed: 0.774 sec <<< ERROR! > java.lang.LinkageError: loader constraint violation: when resolving interface method "com.jayway.restassured.specification.ResponseSpecification.statusCode(Lorg/hamcrest/Matcher;)Lcom/jayway/restassured/specification/ResponseSpecification;" the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the current class, org/testing/web/TroubleIT, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for resolved class, com/jayway/restassured/specification/ResponseSpecification, have different Class objects for the type cification.statusCode(Lorg/hamcrest/Matcher;)Lcom/jayway/restassured/specification/ResponseSpecification; used in the signature > at org.testing.web.TroubleIT.testTrouble(TroubleIT.java:35) > {code} > This error can be resolved in three different ways: > - Rewrite the test using TestNG > - Rewrite the test without using any Hamcrest matchers. > - Remove "org.hamcrest" from {{org.jboss.arquillian.junit.container.JUnitDeploymentAppender}}. > See [Issue #78 for arquillian-core|https://github.com/arquillian/arquillian-core/issues/78] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 06:37:18 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 20 Apr 2015 06:37:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1945) Update to Jacoco 0.7.4 In-Reply-To: References: Message-ID: Aslak Knutsen created ARQ-1945: ---------------------------------- Summary: Update to Jacoco 0.7.4 Key: ARQ-1945 URL: https://issues.jboss.org/browse/ARQ-1945 Project: Arquillian Issue Type: Feature Request Components: Extension - Jacoco Reporter: Aslak Knutsen -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 06:37:18 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 20 Apr 2015 06:37:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1945) Update to Jacoco 0.7.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1945: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-extension-jacoco/pull/18 > Update to Jacoco 0.7.4 > ---------------------- > > Key: ARQ-1945 > URL: https://issues.jboss.org/browse/ARQ-1945 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Jacoco > Reporter: Aslak Knutsen > Fix For: jacoco_1.0.0.next > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 06:37:19 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 20 Apr 2015 06:37:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1945) Update to Jacoco 0.7.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1945: ------------------------------- Fix Version/s: jacoco_1.0.0.next > Update to Jacoco 0.7.4 > ---------------------- > > Key: ARQ-1945 > URL: https://issues.jboss.org/browse/ARQ-1945 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Jacoco > Reporter: Aslak Knutsen > Fix For: jacoco_1.0.0.next > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 06:38:18 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 20 Apr 2015 06:38:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1936) Jacoco Extension needs signature removal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1936: ------------------------------- Fix Version/s: jacoco_1.0.0.next > Jacoco Extension needs signature removal > ---------------------------------------- > > Key: ARQ-1936 > URL: https://issues.jboss.org/browse/ARQ-1936 > Project: Arquillian > Issue Type: Bug > Components: Extension - Jacoco > Environment: WildFly 8.2.0.Final > Reporter: Arcadiy Ivanov > Fix For: jacoco_1.0.0.next > > > Jacoco normally removes signatures using SignatureRemover. Because Arq Jacoco Extension is dealing with Archives and Assets it invokes instrumenter directly by hand. The normal process of signature removal doesn't happen and corrupted jars fail to be read with errors such as this. > {noformat} > 2015-03-21 07:49:08,062 WARN [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015852: Could not index class org/jacoco/core/internal/flow/ClassProbesAdapter.class at /content/27ab3865-48b4-48c0-b2b5-dbbfd128ed38.ear/lib/org.jacoco.core-0.7.4.201502262128.jar: java.lang.SecurityException: SHA-256 digest error for org/jacoco/core/internal/flow/ClassProbesAdapter.class > at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:218) [rt.jar:1.8.0_40] > at java.util.jar.JarVerifier.processEntry(JarVerifier.java:241) [rt.jar:1.8.0_40] > at java.util.jar.JarVerifier.update(JarVerifier.java:228) [rt.jar:1.8.0_40] > at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:482) [rt.jar:1.8.0_40] > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) [rt.jar:1.8.0_40] > at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) [rt.jar:1.8.0_40] > at java.io.BufferedInputStream.read(BufferedInputStream.java:345) [rt.jar:1.8.0_40] > at java.io.DataInputStream.readFully(DataInputStream.java:195) [rt.jar:1.8.0_40] > at java.io.DataInputStream.readFully(DataInputStream.java:169) [rt.jar:1.8.0_40] > at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:433) [jandex-1.2.1.Final.jar:1.2.1.Final] > at org.jboss.jandex.Indexer.index(Indexer.java:689) [jandex-1.2.1.Final.jar:1.2.1.Final] > at org.jboss.as.server.deployment.annotation.ResourceRootIndexer.indexResourceRoot(ResourceRootIndexer.java:100) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.as.server.deployment.annotation.AnnotationIndexProcessor.deploy(AnnotationIndexProcessor.java:51) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 06:48:19 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 20 Apr 2015 06:48:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1945) Update to Jacoco 0.7.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1945: ------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Aslak Knutsen Resolution: Done upstream https://github.com/arquillian/arquillian-extension-jacoco/commit/09fbda53580ad28cf6e097dc22bc51ba8fb69548 > Update to Jacoco 0.7.4 > ---------------------- > > Key: ARQ-1945 > URL: https://issues.jboss.org/browse/ARQ-1945 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Jacoco > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: jacoco_1.0.0.next > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 06:48:20 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 20 Apr 2015 06:48:20 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1936) Jacoco Extension needs signature removal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen resolved ARQ-1936. -------------------------------- Assignee: Aslak Knutsen Resolution: Done upstream https://github.com/arquillian/arquillian-extension-jacoco/commit/115932979a6bd1a0fb2f657341647b6713cee6d7 > Jacoco Extension needs signature removal > ---------------------------------------- > > Key: ARQ-1936 > URL: https://issues.jboss.org/browse/ARQ-1936 > Project: Arquillian > Issue Type: Bug > Components: Extension - Jacoco > Environment: WildFly 8.2.0.Final > Reporter: Arcadiy Ivanov > Assignee: Aslak Knutsen > Fix For: jacoco_1.0.0.next > > > Jacoco normally removes signatures using SignatureRemover. Because Arq Jacoco Extension is dealing with Archives and Assets it invokes instrumenter directly by hand. The normal process of signature removal doesn't happen and corrupted jars fail to be read with errors such as this. > {noformat} > 2015-03-21 07:49:08,062 WARN [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015852: Could not index class org/jacoco/core/internal/flow/ClassProbesAdapter.class at /content/27ab3865-48b4-48c0-b2b5-dbbfd128ed38.ear/lib/org.jacoco.core-0.7.4.201502262128.jar: java.lang.SecurityException: SHA-256 digest error for org/jacoco/core/internal/flow/ClassProbesAdapter.class > at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:218) [rt.jar:1.8.0_40] > at java.util.jar.JarVerifier.processEntry(JarVerifier.java:241) [rt.jar:1.8.0_40] > at java.util.jar.JarVerifier.update(JarVerifier.java:228) [rt.jar:1.8.0_40] > at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:482) [rt.jar:1.8.0_40] > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) [rt.jar:1.8.0_40] > at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) [rt.jar:1.8.0_40] > at java.io.BufferedInputStream.read(BufferedInputStream.java:345) [rt.jar:1.8.0_40] > at java.io.DataInputStream.readFully(DataInputStream.java:195) [rt.jar:1.8.0_40] > at java.io.DataInputStream.readFully(DataInputStream.java:169) [rt.jar:1.8.0_40] > at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:433) [jandex-1.2.1.Final.jar:1.2.1.Final] > at org.jboss.jandex.Indexer.index(Indexer.java:689) [jandex-1.2.1.Final.jar:1.2.1.Final] > at org.jboss.as.server.deployment.annotation.ResourceRootIndexer.indexResourceRoot(ResourceRootIndexer.java:100) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.as.server.deployment.annotation.AnnotationIndexProcessor.deploy(AnnotationIndexProcessor.java:51) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 07:11:19 2015 From: issues at jboss.org (Romain Pelisse (JIRA)) Date: Mon, 20 Apr 2015 07:11:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1479) NoSuchMethodError with weld se container and junit continer 1.1.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060557#comment-13060557 ] Romain Pelisse commented on ARQ-1479: ------------------------------------- Hi, I hate to be the one reopening issue, but I've more/less follow the Arquillian tutorial, and I ran in the same issue, that I've resolved using Scott Starke proposed workaround. If you want to reproduce it, simply checkout out the following branch on my github account: https://github.com/rpelisse/Belarquian/tree/ARQ-1479 > NoSuchMethodError with weld se container and junit continer 1.1.1 > ----------------------------------------------------------------- > > Key: ARQ-1479 > URL: https://issues.jboss.org/browse/ARQ-1479 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Affects Versions: weld_1.0.0.CR7 > Reporter: Shay Matasaro > Assignee: Aslak Knutsen > > when using the weld-se 1.0.0.cr7 container with junit 1.1.1 container an exception is thrown: > java.lang.NoSuchMethodError: org.jboss.arquillian.container.spi.client.deployment.Validate.archiveHasExpectedFileExtension(Lorg/jboss/shrinkwrap/api/Archive;)Z > at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.logWarningIfArchiveHasUnexpectedFileExtension(AnnotationDeploymentScenarioGenerator.java:130) > at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generateDeployment(AnnotationDeploymentScenarioGenerator.java:100) > at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generate(AnnotationDeploymentScenarioGenerator.java:62) > at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:100) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:75) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 07:15:21 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 20 Apr 2015 07:15:21 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1936) Jacoco Extension needs signature removal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1936: ------------------------------- Fix Version/s: jacoco_1.0.0.Alpha8 (was: jacoco_1.0.0.next) > Jacoco Extension needs signature removal > ---------------------------------------- > > Key: ARQ-1936 > URL: https://issues.jboss.org/browse/ARQ-1936 > Project: Arquillian > Issue Type: Bug > Components: Extension - Jacoco > Environment: WildFly 8.2.0.Final > Reporter: Arcadiy Ivanov > Assignee: Aslak Knutsen > Fix For: jacoco_1.0.0.Alpha8 > > > Jacoco normally removes signatures using SignatureRemover. Because Arq Jacoco Extension is dealing with Archives and Assets it invokes instrumenter directly by hand. The normal process of signature removal doesn't happen and corrupted jars fail to be read with errors such as this. > {noformat} > 2015-03-21 07:49:08,062 WARN [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015852: Could not index class org/jacoco/core/internal/flow/ClassProbesAdapter.class at /content/27ab3865-48b4-48c0-b2b5-dbbfd128ed38.ear/lib/org.jacoco.core-0.7.4.201502262128.jar: java.lang.SecurityException: SHA-256 digest error for org/jacoco/core/internal/flow/ClassProbesAdapter.class > at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:218) [rt.jar:1.8.0_40] > at java.util.jar.JarVerifier.processEntry(JarVerifier.java:241) [rt.jar:1.8.0_40] > at java.util.jar.JarVerifier.update(JarVerifier.java:228) [rt.jar:1.8.0_40] > at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:482) [rt.jar:1.8.0_40] > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) [rt.jar:1.8.0_40] > at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) [rt.jar:1.8.0_40] > at java.io.BufferedInputStream.read(BufferedInputStream.java:345) [rt.jar:1.8.0_40] > at java.io.DataInputStream.readFully(DataInputStream.java:195) [rt.jar:1.8.0_40] > at java.io.DataInputStream.readFully(DataInputStream.java:169) [rt.jar:1.8.0_40] > at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:433) [jandex-1.2.1.Final.jar:1.2.1.Final] > at org.jboss.jandex.Indexer.index(Indexer.java:689) [jandex-1.2.1.Final.jar:1.2.1.Final] > at org.jboss.as.server.deployment.annotation.ResourceRootIndexer.indexResourceRoot(ResourceRootIndexer.java:100) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.as.server.deployment.annotation.AnnotationIndexProcessor.deploy(AnnotationIndexProcessor.java:51) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 07:15:21 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 20 Apr 2015 07:15:21 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1945) Update to Jacoco 0.7.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen updated ARQ-1945: ------------------------------- Fix Version/s: jacoco_1.0.0.Alpha8 (was: jacoco_1.0.0.next) > Update to Jacoco 0.7.4 > ---------------------- > > Key: ARQ-1945 > URL: https://issues.jboss.org/browse/ARQ-1945 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Jacoco > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: jacoco_1.0.0.Alpha8 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 07:16:19 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 20 Apr 2015 07:16:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1945) Update to Jacoco 0.7.4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1945. ------------------------------ > Update to Jacoco 0.7.4 > ---------------------- > > Key: ARQ-1945 > URL: https://issues.jboss.org/browse/ARQ-1945 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Jacoco > Reporter: Aslak Knutsen > Assignee: Aslak Knutsen > Fix For: jacoco_1.0.0.Alpha8 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 07:16:19 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Mon, 20 Apr 2015 07:16:19 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1936) Jacoco Extension needs signature removal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aslak Knutsen closed ARQ-1936. ------------------------------ > Jacoco Extension needs signature removal > ---------------------------------------- > > Key: ARQ-1936 > URL: https://issues.jboss.org/browse/ARQ-1936 > Project: Arquillian > Issue Type: Bug > Components: Extension - Jacoco > Environment: WildFly 8.2.0.Final > Reporter: Arcadiy Ivanov > Assignee: Aslak Knutsen > Fix For: jacoco_1.0.0.Alpha8 > > > Jacoco normally removes signatures using SignatureRemover. Because Arq Jacoco Extension is dealing with Archives and Assets it invokes instrumenter directly by hand. The normal process of signature removal doesn't happen and corrupted jars fail to be read with errors such as this. > {noformat} > 2015-03-21 07:49:08,062 WARN [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015852: Could not index class org/jacoco/core/internal/flow/ClassProbesAdapter.class at /content/27ab3865-48b4-48c0-b2b5-dbbfd128ed38.ear/lib/org.jacoco.core-0.7.4.201502262128.jar: java.lang.SecurityException: SHA-256 digest error for org/jacoco/core/internal/flow/ClassProbesAdapter.class > at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:218) [rt.jar:1.8.0_40] > at java.util.jar.JarVerifier.processEntry(JarVerifier.java:241) [rt.jar:1.8.0_40] > at java.util.jar.JarVerifier.update(JarVerifier.java:228) [rt.jar:1.8.0_40] > at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:482) [rt.jar:1.8.0_40] > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) [rt.jar:1.8.0_40] > at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) [rt.jar:1.8.0_40] > at java.io.BufferedInputStream.read(BufferedInputStream.java:345) [rt.jar:1.8.0_40] > at java.io.DataInputStream.readFully(DataInputStream.java:195) [rt.jar:1.8.0_40] > at java.io.DataInputStream.readFully(DataInputStream.java:169) [rt.jar:1.8.0_40] > at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:433) [jandex-1.2.1.Final.jar:1.2.1.Final] > at org.jboss.jandex.Indexer.index(Indexer.java:689) [jandex-1.2.1.Final.jar:1.2.1.Final] > at org.jboss.as.server.deployment.annotation.ResourceRootIndexer.indexResourceRoot(ResourceRootIndexer.java:100) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.as.server.deployment.annotation.AnnotationIndexProcessor.deploy(AnnotationIndexProcessor.java:51) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 09:46:18 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Mon, 20 Apr 2015 09:46:18 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060634#comment-13060634 ] Chris Rankin commented on ARQ-1943: ----------------------------------- [The plot thickens|https://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_bean_archive_isolation]: {quote}In general, an implicit bean archive does not have to contain a beans.xml descriptor. However, such a bean archive is not supported by Weld Servlet, i.e. it?s excluded from discovery.{quote} My Tomcat is indeed using Weld Servlet, which means my bean archive _must_ contain a {{beans.xml}} descriptor. And toggling the {{org.jboss.weld.environment.servlet.archive.isolation}} context parameter has the following effect: || {{org.jboss.weld.environment.servlet.archive.isolation}} || Bean instances || | true | 2 | | false | 0 | > Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive > -------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1943 > URL: https://issues.jboss.org/browse/ARQ-1943 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Environment: Windows 7 x64, Linux x64, JDK7 > Reporter: Chris Rankin > Attachments: arquillian-test.tar.xz, arquillian-test.tar.xz > > > Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: > I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: > - a @Dependent bean with a @Produces method > - a META-INF/beans.xml file. > When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: > SEVERE: Servlet threw load() exception > org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble > at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble > at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) > Possible dependencies: > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Apr 20 11:51:20 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Mon, 20 Apr 2015 11:51:20 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails with weld-servlet >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Rankin updated ARQ-1943: ------------------------------ Summary: Deployment fails with weld-servlet >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive (was: Deployment fails with WELD >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive) > Deployment fails with weld-servlet >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive > ---------------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1943 > URL: https://issues.jboss.org/browse/ARQ-1943 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Environment: Windows 7 x64, Linux x64, JDK7 > Reporter: Chris Rankin > Attachments: arquillian-test.tar.xz, arquillian-test.tar.xz > > > Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: > I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: > - a @Dependent bean with a @Produces method > - a META-INF/beans.xml file. > When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: > SEVERE: Servlet threw load() exception > org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble > at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble > at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) > Possible dependencies: > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Apr 21 04:40:20 2015 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Tue, 21 Apr 2015 04:40:20 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1924) Bad behaviour on Shrinkwrap.addAsServiceProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060880#comment-13060880 ] Antonin Stefanutti commented on ARQ-1924: ----------------------------------------- I've been facing the same issue in https://github.com/astefanutti/further-cdi/blob/b490b41747b70b0e5a28f05ba3e5ef20ec5dcd3c/camel/further/src/test/java/io/astefanutti/cdi/further/camel/FurtherCdiCamelTest.java#L36. In my case, the extension added with {{addAsServiceProvider}} is not deployed by the CDI container managed by the {{arquillian-weld-ee-embedded-1.1}} adapter when I create an EAR, while that works when I create a WAR. As mentioned in the description, the extension is deployed as expected in the CDI container managed by the {{wildfly-arquillian-container-managed}} adapter. I'd suggest to update the title to be more specific so that users don't lose too much time trying to troubleshoot why extensions are not properly deployed when being added with {{addAsServiceProvider}}. > Bad behaviour on Shrinkwrap.addAsServiceProvider > ------------------------------------------------ > > Key: ARQ-1924 > URL: https://issues.jboss.org/browse/ARQ-1924 > Project: Arquillian > Issue Type: Bug > Components: OpenWebBeans Containers, Weld Containers > Affects Versions: 1.0.0.CR8, 1.1.7.Final > Reporter: Rafael Benevides > Attachments: arquillian-test.zip > > > The attached maven project contains two tests: > 1 - ExtensionInJarTest - This adds a Service through .addAsServiceProvider to an JAR that is placed inside a WAR > 2 - ExtensionInWarTest - This add a Service through .addAsServiceProvider directly to a WAR > If you run the tests inside Wildfly: > {code} > mvn clean test -Parq-wildfly-remote //it works > {code} > If you run the tests using Weld or OWB: > {code} > mvn clean test -PWeld //it fails on ExtensionInJarTest > mvn clean test -POWB //it fails on ExtensionInJarTest > {code} > The expected behaviour is that Weld and OWB shouldn't fail. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Apr 21 04:46:20 2015 From: issues at jboss.org (Antonin Stefanutti (JIRA)) Date: Tue, 21 Apr 2015 04:46:20 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1924) Bad behaviour on Shrinkwrap.addAsServiceProvider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060880#comment-13060880 ] Antonin Stefanutti edited comment on ARQ-1924 at 4/21/15 4:45 AM: ------------------------------------------------------------------ I've been reproducing the same issue in https://github.com/astefanutti/further-cdi/blob/b490b41747b70b0e5a28f05ba3e5ef20ec5dcd3c/camel/further/src/test/java/io/astefanutti/cdi/further/camel/FurtherCdiCamelTest.java#L36. In my case, the extension added with {{addAsServiceProvider}} is not deployed by the CDI container managed by the {{arquillian-weld-ee-embedded-1.1}} adapter when I create an EAR, while that works when I create a WAR. As mentioned in the description, the extension is deployed as expected in the CDI container managed by the {{wildfly-arquillian-container-managed}} adapter. I'd suggest to update the title to be more specific so that users don't lose too much time trying to troubleshoot why extensions are not properly deployed when being added with {{addAsServiceProvider}}. was (Author: stefanutti): I've been facing the same issue in https://github.com/astefanutti/further-cdi/blob/b490b41747b70b0e5a28f05ba3e5ef20ec5dcd3c/camel/further/src/test/java/io/astefanutti/cdi/further/camel/FurtherCdiCamelTest.java#L36. In my case, the extension added with {{addAsServiceProvider}} is not deployed by the CDI container managed by the {{arquillian-weld-ee-embedded-1.1}} adapter when I create an EAR, while that works when I create a WAR. As mentioned in the description, the extension is deployed as expected in the CDI container managed by the {{wildfly-arquillian-container-managed}} adapter. I'd suggest to update the title to be more specific so that users don't lose too much time trying to troubleshoot why extensions are not properly deployed when being added with {{addAsServiceProvider}}. > Bad behaviour on Shrinkwrap.addAsServiceProvider > ------------------------------------------------ > > Key: ARQ-1924 > URL: https://issues.jboss.org/browse/ARQ-1924 > Project: Arquillian > Issue Type: Bug > Components: OpenWebBeans Containers, Weld Containers > Affects Versions: 1.0.0.CR8, 1.1.7.Final > Reporter: Rafael Benevides > Attachments: arquillian-test.zip > > > The attached maven project contains two tests: > 1 - ExtensionInJarTest - This adds a Service through .addAsServiceProvider to an JAR that is placed inside a WAR > 2 - ExtensionInWarTest - This add a Service through .addAsServiceProvider directly to a WAR > If you run the tests inside Wildfly: > {code} > mvn clean test -Parq-wildfly-remote //it works > {code} > If you run the tests using Weld or OWB: > {code} > mvn clean test -PWeld //it fails on ExtensionInJarTest > mvn clean test -POWB //it fails on ExtensionInJarTest > {code} > The expected behaviour is that Weld and OWB shouldn't fail. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Apr 21 19:20:33 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Tue, 21 Apr 2015 19:20:33 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails with weld-servlet >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Rankin resolved ARQ-1943. ------------------------------- Resolution: Done Martin Kouba has revealed to me that I need to configure maven-failsafe-plugin as follows before the bean archive will work in an embedded container: {code:XML} maven-failsafe-plugin testing:test-weld ... {code} > Deployment fails with weld-servlet >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive > ---------------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1943 > URL: https://issues.jboss.org/browse/ARQ-1943 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Environment: Windows 7 x64, Linux x64, JDK7 > Reporter: Chris Rankin > Attachments: arquillian-test.tar.xz, arquillian-test.tar.xz > > > Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: > I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: > - a @Dependent bean with a @Produces method > - a META-INF/beans.xml file. > When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: > SEVERE: Servlet threw load() exception > org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble > at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble > at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) > Possible dependencies: > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Apr 21 19:20:33 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Tue, 21 Apr 2015 19:20:33 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails with weld-servlet >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Rankin reopened ARQ-1943: ------------------------------- > Deployment fails with weld-servlet >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive > ---------------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1943 > URL: https://issues.jboss.org/browse/ARQ-1943 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Environment: Windows 7 x64, Linux x64, JDK7 > Reporter: Chris Rankin > Attachments: arquillian-test.tar.xz, arquillian-test.tar.xz > > > Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: > I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: > - a @Dependent bean with a @Produces method > - a META-INF/beans.xml file. > When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: > SEVERE: Servlet threw load() exception > org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble > at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble > at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) > Possible dependencies: > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Apr 21 19:20:33 2015 From: issues at jboss.org (Chris Rankin (JIRA)) Date: Tue, 21 Apr 2015 19:20:33 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1943) Deployment fails with weld-servlet >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Rankin resolved ARQ-1943. ------------------------------- Resolution: Rejected > Deployment fails with weld-servlet >= 2.2.5.Final because of duplicate CDI beans when deployment contains bean archive > ---------------------------------------------------------------------------------------------------------------------- > > Key: ARQ-1943 > URL: https://issues.jboss.org/browse/ARQ-1943 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR7 > Environment: Windows 7 x64, Linux x64, JDK7 > Reporter: Chris Rankin > Attachments: arquillian-test.tar.xz, arquillian-test.tar.xz > > > Using arquillian-tomcat-embedded-7, arquillian-bom 1.1.7.Final, WELD 2.2.10.Final: > I have created a simple WAR file that contains WELD and a single servlet. There is also a dependent JAR that contains the following: > - a @Dependent bean with a @Produces method > - a META-INF/beans.xml file. > When I try to test this servlet using Arquillian's TestNG container, the deployment fails with this error: > SEVERE: Servlet threw load() exception > org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble > at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble > at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0) > Possible dependencies: > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()], > - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.TroubleMaker.getTrouble()] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Apr 22 05:43:33 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 22 Apr 2015 05:43:33 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1946) Tomcat embedded container should employ a dedicated ClassLoader In-Reply-To: References: Message-ID: Martin Kouba created ARQ-1946: --------------------------------- Summary: Tomcat embedded container should employ a dedicated ClassLoader Key: ARQ-1946 URL: https://issues.jboss.org/browse/ARQ-1946 Project: Arquillian Issue Type: Bug Components: Tomcat Containers Affects Versions: tomcat_1.0.0.CR6 Reporter: Martin Kouba Currently, it seems the parent CL is used, and so the classpath also contains all project dependencies. See also [the Weld forum reference|https://developer.jboss.org/thread/256067] and [maven-surefire-plugin - Configuring the Classpath|http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html]. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Apr 22 07:37:33 2015 From: issues at jboss.org (Aslak Knutsen (JIRA)) Date: Wed, 22 Apr 2015 07:37:33 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1946) Tomcat embedded container should employ a dedicated ClassLoader In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061456#comment-13061456 ] Aslak Knutsen commented on ARQ-1946: ------------------------------------ This is e general issue with Embedded containers as Arquillian doesn't apply any classloading strategy at all. > Tomcat embedded container should employ a dedicated ClassLoader > ---------------------------------------------------------------- > > Key: ARQ-1946 > URL: https://issues.jboss.org/browse/ARQ-1946 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR6 > Reporter: Martin Kouba > > Currently, it seems the parent CL is used, and so the classpath also contains all project dependencies. See also [the Weld forum reference|https://developer.jboss.org/thread/256067] and [maven-surefire-plugin - Configuring the Classpath|http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html]. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Apr 22 07:49:33 2015 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 22 Apr 2015 07:49:33 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1946) Tomcat embedded container should employ a dedicated ClassLoader In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061461#comment-13061461 ] Martin Kouba commented on ARQ-1946: ----------------------------------- [~aslak] AFAIK it does in case of arquillian-weld-ee-embedded. See also {{org.jboss.arquillian.container.weld.ee.embedded_1_1.WebArchiveClassLoader}}. > Tomcat embedded container should employ a dedicated ClassLoader > ---------------------------------------------------------------- > > Key: ARQ-1946 > URL: https://issues.jboss.org/browse/ARQ-1946 > Project: Arquillian > Issue Type: Bug > Components: Tomcat Containers > Affects Versions: tomcat_1.0.0.CR6 > Reporter: Martin Kouba > > Currently, it seems the parent CL is used, and so the classpath also contains all project dependencies. See also [the Weld forum reference|https://developer.jboss.org/thread/256067] and [maven-surefire-plugin - Configuring the Classpath|http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html]. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Apr 23 06:10:33 2015 From: issues at jboss.org (Romain Pelisse (JIRA)) Date: Thu, 23 Apr 2015 06:10:33 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1479) NoSuchMethodError with weld se container and junit continer 1.1.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061887#comment-13061887 ] Romain Pelisse commented on ARQ-1479: ------------------------------------- Ok, forget my last comment, thanks to Aslak Knutsen I was able to fix my issue, by changing the type of the deps from 'bom' to 'pom'. > NoSuchMethodError with weld se container and junit continer 1.1.1 > ----------------------------------------------------------------- > > Key: ARQ-1479 > URL: https://issues.jboss.org/browse/ARQ-1479 > Project: Arquillian > Issue Type: Bug > Components: Weld Containers > Affects Versions: weld_1.0.0.CR7 > Reporter: Shay Matasaro > Assignee: Aslak Knutsen > > when using the weld-se 1.0.0.cr7 container with junit 1.1.1 container an exception is thrown: > java.lang.NoSuchMethodError: org.jboss.arquillian.container.spi.client.deployment.Validate.archiveHasExpectedFileExtension(Lorg/jboss/shrinkwrap/api/Archive;)Z > at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.logWarningIfArchiveHasUnexpectedFileExtension(AnnotationDeploymentScenarioGenerator.java:130) > at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generateDeployment(AnnotationDeploymentScenarioGenerator.java:100) > at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generate(AnnotationDeploymentScenarioGenerator.java:62) > at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:100) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:75) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Apr 27 07:11:52 2015 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 27 Apr 2015 07:11:52 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1940) arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQ-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler reassigned ARQ-1940: ----------------------------------- Assignee: (was: Thomas Diesler) > arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18 > --------------------------------------------------------------------------------- > > Key: ARQ-1940 > URL: https://issues.jboss.org/browse/ARQ-1940 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Tomas Rohovsky > Priority: Minor > Attachments: surefire-reproducer.zip > > > arquillian-osgi-bundle is not undeployed when executing a test with surefire-plugin 2.18. It works with older versions of surefire-plugin. A reproducer is attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Apr 27 09:52:52 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 27 Apr 2015 09:52:52 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-86) Support XHR Halter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062865#comment-13062865 ] Luk?? Fry? commented on ARQGRA-86: ---------------------------------- Branch where Juraj started working on this feature: https://github.com/jhuska/arquillian-graphene/commits/ARQGRA-86 > Support XHR Halter > ------------------ > > Key: ARQGRA-86 > URL: https://issues.jboss.org/browse/ARQGRA-86 > Project: Arquillian Graphene > Issue Type: Epic > Reporter: Luk?? Fry? > Assignee: Juraj H?ska > Fix For: 2.1-Tracking > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Apr 27 09:54:53 2015 From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=) Date: Mon, 27 Apr 2015 09:54:53 -0400 (EDT) Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-86) Support XHR Halter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ARQGRA-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062865#comment-13062865 ] Luk?? Fry? edited comment on ARQGRA-86 at 4/27/15 9:54 AM: ----------------------------------------------------------- Branch where Juraj started working on this feature: https://github.com/jhuska/arquillian-graphene/commits/ARQGRA-86 [~jhuska] do you remember what was the blocker here? was (Author: lfryc): Branch where Juraj started working on this feature: https://github.com/jhuska/arquillian-graphene/commits/ARQGRA-86 > Support XHR Halter > ------------------ > > Key: ARQGRA-86 > URL: https://issues.jboss.org/browse/ARQGRA-86 > Project: Arquillian Graphene > Issue Type: Epic > Reporter: Luk?? Fry? > Assignee: Juraj H?ska > Fix For: 2.1-Tracking > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)