[JBoss JIRA] (ARQ-1931) Arquillian jacoco extension throws NullpointerException when using 'createFromZipFile'
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1931?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-1931:
--------------------------------
Fix Version/s: jacoco_1.0.0.Alpha9
> Arquillian jacoco extension throws NullpointerException when using 'createFromZipFile'
> --------------------------------------------------------------------------------------
>
> Key: ARQ-1931
> URL: https://issues.jboss.org/browse/ARQ-1931
> Project: Arquillian
> Issue Type: Bug
> Components: Extension - Jacoco
> Affects Versions: jacoco_1.0.0.Alpha8
> Reporter: Johan van Kampen
> Assignee: Dipak Pawar
> Fix For: jacoco_1.0.0.Alpha9
>
> Attachments: dri.zip
>
>
> I use the code below which results in a NullpointerException :
> @Deployment
> public static EnterpriseArchive createEARArchive() {
>
> EnterpriseArchive ear = ShrinkWrap.createFromZipFile(EnterpriseArchive.class, new File("../dri.ear/target/dri.ear-1.0-SNAPSHOT.ear"));
> ear.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
> return ear;
>
> }
>
> Full stacktrace
> java.lang.NullPointerException: null
> at org.jboss.arquillian.extension.jacoco.client.ApplicationArchiveInstrumenter.processArchive(ApplicationArchiveInstrumenter.java:52)
> at org.jboss.arquillian.extension.jacoco.client.ApplicationArchiveInstrumenter.processArchive(ApplicationArchiveInstrumenter.java:68)
> at org.jboss.arquillian.extension.jacoco.client.ApplicationArchiveInstrumenter.process(ApplicationArchiveInstrumenter.java:74)
> at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.applyApplicationProcessors(DeploymentGenerator.java:223)
> at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.buildTestableDeployments(DeploymentGenerator.java:172)
> at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.createTestableDeployments(DeploymentGenerator.java:148)
> at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:85)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:100)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:190)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> 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.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103
>
>
> Using the configuration below, everything works fine. However, this is a relative simple application. I have several much more complex applications for which I would prefer the first configuration. :
> @Deployment
> public static Archive<?> createTestArchive() {
>
> WebArchive war =
> ShrinkWrap.create(WebArchive.class, "test.war")
> .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
>
> war.addAsLibrary(new File("../dri.ejb/target/dri.ejb-1.0-SNAPSHOT.jar"));
>
> return war;
> }
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (ARQ-2053) Allow Arquillian Core to define a way to execute registration of extensions in order
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2053?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2053:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Allow Arquillian Core to define a way to execute registration of extensions in order
> ------------------------------------------------------------------------------------
>
> Key: ARQ-2053
> URL: https://issues.jboss.org/browse/ARQ-2053
> Project: Arquillian
> Issue Type: Bug
> Reporter: Alex Soto
> Assignee: Alex Soto
> Priority: Minor
> Fix For: 1.1.12.Final
>
>
> With Arquillian Extensions you are able to override a service that was previously registered by Arquillian Core or by other extensions.
> The problem is that if if there two extensions that override the same service, it will depend on the order of the registration of the extension that will define which version of the service will be the one used at the end.
> To avoid this problem this problem the best way would be to be able to set a priority in extension registry so you can set which one is going to be the last one.
> The best none invasive approach we have found is by providing an SPI so any extension can vetoed any service /ResourceProvider/TestEnricher/... to be registered by an extension. This SPI is a file present at META-INF directory and called exclusions. The file is a properties file where key is the service type you want to veto such as (`org.jboss.arquillian.test.spi.enricher.resource.ResourceProvider`) and inside all the implementations you want to veto of this kind, each one separated by comma.
> So before starting registering the extensions, the vetoed list will be loaded into service registry so they cannot be registered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (ARQ-2053) Allow Arquillian Core to define a way to execute registration of extensions in order
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2053?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2053:
--------------------------------
Fix Version/s: 1.1.12.Final
> Allow Arquillian Core to define a way to execute registration of extensions in order
> ------------------------------------------------------------------------------------
>
> Key: ARQ-2053
> URL: https://issues.jboss.org/browse/ARQ-2053
> Project: Arquillian
> Issue Type: Bug
> Reporter: Alex Soto
> Assignee: Alex Soto
> Priority: Minor
> Fix For: 1.1.12.Final
>
>
> With Arquillian Extensions you are able to override a service that was previously registered by Arquillian Core or by other extensions.
> The problem is that if if there two extensions that override the same service, it will depend on the order of the registration of the extension that will define which version of the service will be the one used at the end.
> To avoid this problem this problem the best way would be to be able to set a priority in extension registry so you can set which one is going to be the last one.
> The best none invasive approach we have found is by providing an SPI so any extension can vetoed any service /ResourceProvider/TestEnricher/... to be registered by an extension. This SPI is a file present at META-INF directory and called exclusions. The file is a properties file where key is the service type you want to veto such as (`org.jboss.arquillian.test.spi.enricher.resource.ResourceProvider`) and inside all the implementations you want to veto of this kind, each one separated by comma.
> So before starting registering the extensions, the vetoed list will be loaded into service registry so they cannot be registered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (ARQ-2053) Allow Arquillian Core to define a way to execute registration of extensions in order
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2053?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak closed ARQ-2053.
-------------------------------
> Allow Arquillian Core to define a way to execute registration of extensions in order
> ------------------------------------------------------------------------------------
>
> Key: ARQ-2053
> URL: https://issues.jboss.org/browse/ARQ-2053
> Project: Arquillian
> Issue Type: Bug
> Reporter: Alex Soto
> Assignee: Alex Soto
> Priority: Minor
> Fix For: 1.1.12.Final
>
>
> With Arquillian Extensions you are able to override a service that was previously registered by Arquillian Core or by other extensions.
> The problem is that if if there two extensions that override the same service, it will depend on the order of the registration of the extension that will define which version of the service will be the one used at the end.
> To avoid this problem this problem the best way would be to be able to set a priority in extension registry so you can set which one is going to be the last one.
> The best none invasive approach we have found is by providing an SPI so any extension can vetoed any service /ResourceProvider/TestEnricher/... to be registered by an extension. This SPI is a file present at META-INF directory and called exclusions. The file is a properties file where key is the service type you want to veto such as (`org.jboss.arquillian.test.spi.enricher.resource.ResourceProvider`) and inside all the implementations you want to veto of this kind, each one separated by comma.
> So before starting registering the extensions, the vetoed list will be loaded into service registry so they cannot be registered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (ARQ-2053) Allow Arquillian Core to define a way to execute registration of extensions in order
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2053?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak reassigned ARQ-2053:
-----------------------------------
Assignee: Alex Soto
> Allow Arquillian Core to define a way to execute registration of extensions in order
> ------------------------------------------------------------------------------------
>
> Key: ARQ-2053
> URL: https://issues.jboss.org/browse/ARQ-2053
> Project: Arquillian
> Issue Type: Bug
> Reporter: Alex Soto
> Assignee: Alex Soto
> Priority: Minor
> Fix For: 1.1.12.Final
>
>
> With Arquillian Extensions you are able to override a service that was previously registered by Arquillian Core or by other extensions.
> The problem is that if if there two extensions that override the same service, it will depend on the order of the registration of the extension that will define which version of the service will be the one used at the end.
> To avoid this problem this problem the best way would be to be able to set a priority in extension registry so you can set which one is going to be the last one.
> The best none invasive approach we have found is by providing an SPI so any extension can vetoed any service /ResourceProvider/TestEnricher/... to be registered by an extension. This SPI is a file present at META-INF directory and called exclusions. The file is a properties file where key is the service type you want to veto such as (`org.jboss.arquillian.test.spi.enricher.resource.ResourceProvider`) and inside all the implementations you want to veto of this kind, each one separated by comma.
> So before starting registering the extensions, the vetoed list will be loaded into service registry so they cannot be registered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (ARQ-2053) Allow Arquillian Core to define a way to execute registration of extensions in order
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2053?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2053:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/arquillian/arquillian-core/pull/118
> Allow Arquillian Core to define a way to execute registration of extensions in order
> ------------------------------------------------------------------------------------
>
> Key: ARQ-2053
> URL: https://issues.jboss.org/browse/ARQ-2053
> Project: Arquillian
> Issue Type: Bug
> Reporter: Alex Soto
> Priority: Minor
>
> With Arquillian Extensions you are able to override a service that was previously registered by Arquillian Core or by other extensions.
> The problem is that if if there two extensions that override the same service, it will depend on the order of the registration of the extension that will define which version of the service will be the one used at the end.
> To avoid this problem this problem the best way would be to be able to set a priority in extension registry so you can set which one is going to be the last one.
> The best none invasive approach we have found is by providing an SPI so any extension can vetoed any service /ResourceProvider/TestEnricher/... to be registered by an extension. This SPI is a file present at META-INF directory and called exclusions. The file is a properties file where key is the service type you want to veto such as (`org.jboss.arquillian.test.spi.enricher.resource.ResourceProvider`) and inside all the implementations you want to veto of this kind, each one separated by comma.
> So before starting registering the extensions, the vetoed list will be loaded into service registry so they cannot be registered.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months