March 2013 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKWRAP-444) Deploy fail on ZipException("error in opening zip file") when ShrinkWrap.createFromZipFile is used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-444?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated SHRINKWRAP-444: ----------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=918442 > Deploy fail on ZipException("error in opening zip file") when ShrinkWrap.createFromZipFile is used > -------------------------------------------------------------------------------------------------- > > Key: SHRINKWRAP-444 > URL: https://issues.jboss.org/browse/SHRINKWRAP-444 > Project: ShrinkWrap > Issue Type: Bug > Affects Versions: 1.1.1 > Reporter: Tomas Hradec > > How to reproduce: > This bug appeared when deploying war archive into EAP 6.0.1. The archive was created by `ShrinkWrap.createFromZipFile(WebArchive.class, new File("path to war"))`. And it has to contain embedded library, which size is greater than few kilobytes, on tiny sizes it didn't appear. > My test archive has following structure and size 670kB. > {code} > test.war: > /WEB-INF/ > /WEB-INF/lib/ > /WEB-INF/lib/hsqldb-1.8.0.10.jar > /WEB-INF/web.xml > /WEB-INF/classes/ > /WEB-INF/classes/org/ > /WEB-INF/classes/org/jboss/ > /WEB-INF/classes/org/jboss/wfk/ > /WEB-INF/classes/org/jboss/wfk/test/ > /WEB-INF/classes/org/jboss/wfk/test/arquillian/ > /WEB-INF/classes/org/jboss/wfk/test/arquillian/HelloWorldServlet.class > {code} > Stack trace: > {code} > org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy to container: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"stub9.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"stub9.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"stub9.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" > Caused by: java.util.zip.ZipException: error in opening zip file"}} > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:74) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:148) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > 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:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > 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:601) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > 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.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > 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:101) > 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:601) > 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:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > 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:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > 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:300) > 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) > Caused by: java.lang.Exception: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"stub9.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"stub9.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"stub9.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" > Caused by: java.util.zip.ZipException: error in opening zip file"}} > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.arquillian.container.ArchiveDeployer.executeDeploymentPlan(ArchiveDeployer.java:91) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:58) > ... 88 more > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-444) Deploy fail on ZipException("error in opening zip file") when ShrinkWrap.createFromZipFile is used

by Tomas Hradec (JIRA)

Tomas Hradec created SHRINKWRAP-444: --------------------------------------- Summary: Deploy fail on ZipException("error in opening zip file") when ShrinkWrap.createFromZipFile is used Key: SHRINKWRAP-444 URL: https://issues.jboss.org/browse/SHRINKWRAP-444 Project: ShrinkWrap Issue Type: Bug Affects Versions: 1.1.1 Reporter: Tomas Hradec How to reproduce: This bug appeared when deploying war archive into EAP 6.0.1. The archive was created by `ShrinkWrap.createFromZipFile(WebArchive.class, new File("path to war"))`. And it has to contain embedded library, which size is greater than few kilobytes, on tiny sizes it didn't appear. My test archive has following structure and size 670kB. {code} test.war: /WEB-INF/ /WEB-INF/lib/ /WEB-INF/lib/hsqldb-1.8.0.10.jar /WEB-INF/web.xml /WEB-INF/classes/ /WEB-INF/classes/org/ /WEB-INF/classes/org/jboss/ /WEB-INF/classes/org/jboss/wfk/ /WEB-INF/classes/org/jboss/wfk/test/ /WEB-INF/classes/org/jboss/wfk/test/arquillian/ /WEB-INF/classes/org/jboss/wfk/test/arquillian/HelloWorldServlet.class {code} Stack trace: {code} org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy to container: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"stub9.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"stub9.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"stub9.war\" Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" Caused by: java.util.zip.ZipException: error in opening zip file"}} at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:74) at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:148) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) 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:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) 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:601) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) 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.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) 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:101) 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:601) 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:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) 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:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) 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:300) 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) Caused by: java.lang.Exception: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"stub9.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"stub9.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"stub9.war\" Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037: Failed to process WEB-INF/lib: \"/content/stub9.war/WEB-INF/lib/hsqldb-1.8.0.10.jar\" Caused by: java.util.zip.ZipException: error in opening zip file"}} at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) at org.jboss.as.arquillian.container.ArchiveDeployer.executeDeploymentPlan(ArchiveDeployer.java:91) at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:58) ... 88 more {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-433) Race condition deadlock in TarGz Exporter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-433?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on SHRINKWRAP-433: ---------------------------------------------------- Marek Novotny <mnovotny(a)redhat.com> made a comment on [bug 875031|https://bugzilla.redhat.com/show_bug.cgi?id=875031] upgrade was reverted to previous version 1.0.0 > Race condition deadlock in TarGz Exporter > ----------------------------------------- > > Key: SHRINKWRAP-433 > URL: https://issues.jboss.org/browse/SHRINKWRAP-433 > Project: ShrinkWrap > Issue Type: Bug > Components: impl-base > Affects Versions: 1.0.1 > Environment: RHEL6 32bit + Oracle JDK 6, Oracle JDK 7, OpenJDK 7 > Windows 2008 32 bit + Oracle JDK 7 > Solaris 10 32 bit + Oracle JDK 6, Oracle JDK 7 > Reporter: Karel Piwko > Assignee: Michal Matloka > Fix For: 1.1.1 > > > There is a deadlock which is triggered on various platforms concerning handling of TarGz archives. Concerned environments are listed in the environment field. > Following error is logged by Jenkins > {code} > 11:48:05 Running org.jboss.shrinkwrap.impl.base.exporter.TarGzExporterTestCase > 16:45:04 Build timed out (after 300 minutes). Marking the build as aborted. > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-433) Race condition deadlock in TarGz Exporter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-433?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on SHRINKWRAP-433: ---------------------------------------------------- Marek Novotny <mnovotny(a)redhat.com> changed the Status of [bug 875031|https://bugzilla.redhat.com/show_bug.cgi?id=875031] from MODIFIED to ASSIGNED > Race condition deadlock in TarGz Exporter > ----------------------------------------- > > Key: SHRINKWRAP-433 > URL: https://issues.jboss.org/browse/SHRINKWRAP-433 > Project: ShrinkWrap > Issue Type: Bug > Components: impl-base > Affects Versions: 1.0.1 > Environment: RHEL6 32bit + Oracle JDK 6, Oracle JDK 7, OpenJDK 7 > Windows 2008 32 bit + Oracle JDK 7 > Solaris 10 32 bit + Oracle JDK 6, Oracle JDK 7 > Reporter: Karel Piwko > Assignee: Michal Matloka > Fix For: 1.1.1 > > > There is a deadlock which is triggered on various platforms concerning handling of TarGz archives. Concerned environments are listed in the environment field. > Following error is logged by Jenkins > {code} > 11:48:05 Running org.jboss.shrinkwrap.impl.base.exporter.TarGzExporterTestCase > 16:45:04 Build timed out (after 300 minutes). Marking the build as aborted. > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-114) Support resolution of versions from a specific artifact

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-114?page=com.atlassian.jira.plu... ] Michal Matloka edited comment on SHRINKRES-114 at 3/1/13 5:36 PM: ------------------------------------------------------------------ Version range requests returns versions info data, not dependencies. Forge team indicates that they would like to get those versions info to get further only e.g. highest version, without transferring all versions files. This probaby requieres some API additions e.g. * addition of resolveVersions method in ResolveStage * resolveVersions would return e.g. wrapped VersionRangeResult object providing getHighest etc methods converting aether Version e.g. to MavenCoordinate Example: {code} final MavenCoordinate mavenCoordinate = Maven.resolver().resolveVersions("groupId:artifactId:[1.0,2.0)").getHighest(); {code} It is not a perfect solution yet, because then SWR has to be used second time to get real files. {code} Maven.resolver().resolve(mavenCoordinate ).with.... {code} But this also brings problem, that resolveVersions shouldnt be executed after resolve... was (Author: mmatloka): Version range requests returns versions info data, not dependencies. Forge team indicates that they would like to get those versions info to get further only e.g. highest version, without transferring all versions files. This probaby requieres some API additions e.g. * addition of resolveVersions method in ResolveStage * resolveVersions would return e.g. wrapped VersionRangeResult object providing getHighest etc methods converting aether Version e.g. to MavenCoordinate Example: {code} final MavenCoordinate mavenCoordinate = Maven.resolver().resolveVersions("groupId:artifactId:[1.0,2.0)").getHighest(); {code} It is not a perfect solution yet, because then SWR has to be used second time to get real files. {code} Maven.resolver().resolve(mavenCoordinate ).with.... {code} > Support resolution of versions from a specific artifact > ------------------------------------------------------- > > Key: SHRINKRES-114 > URL: https://issues.jboss.org/browse/SHRINKRES-114 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-beta-2 > Reporter: George Gastaldi > Assignee: Michal Matloka > > There are cases where a version of a specific artifact is unknown during test execution. > Aether supports version ranging: > {code}org.sonatype.aether.RepositorySystem.resolveVersionRange(RepositorySystemSession, VersionRangeRequest){code} > It would be nice to provide an API in ShrinkWrap Resolver to: > - Resolve the available versions from a specific given range > - From that range, the possibility to retrieve the lowest and the highest version > - Reuse this information to resolve artifacts using the already existing ShrinkWrap Resolver APIs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-114) Support resolution of versions from a specific artifact

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-114?page=com.atlassian.jira.plu... ] Michal Matloka edited comment on SHRINKRES-114 at 3/1/13 5:03 PM: ------------------------------------------------------------------ Version range requests returns versions info data, not dependencies. Forge team indicates that they would like to get those versions info to get further only e.g. highest version, without transferring all versions files. This probaby requieres some API additions e.g. * addition of resolveVersions method in ResolveStage * resolveVersions would return e.g. wrapped VersionRangeResult object providing getHighest etc methods converting aether Version e.g. to MavenCoordinate Example: {code} final MavenCoordinate mavenCoordinate = Maven.resolver().resolveVersions("groupId:artifactId:[1.0,2.0)").getHighest(); {code} It is not a perfect solution yet, because then SWR has to be used second time to get real files. {code} Maven.resolver().resolve(mavenCoordinate ).with.... {code} was (Author: mmatloka): Version range requests returns versions info data, not dependencies. Forge team indicates that they would like to get those versions info to get further only e.g. highest version, without transferring all versions files. This probaby requieres some API additions e.g. * addition of resolveVersions method in ResolveStage * resolveVersions would return e.g. wrapped VersionRangeResult object providing getHighest etc methods converting aether Version e.g. to Maven Artifact Info Example: {code} final MavenArtifactInfo mavenArtifactInfo = Maven.resolver().resolveVersions("groupId:artifactId:[1.0,2.0)").getHighest(); {code} It is not a perfect solution yet, because then SWR has to be used second time to get real files. {code} Maven.resolver().resolve(mavenArtifactInfo.getCoordinate).with.... {code} > Support resolution of versions from a specific artifact > ------------------------------------------------------- > > Key: SHRINKRES-114 > URL: https://issues.jboss.org/browse/SHRINKRES-114 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-beta-2 > Reporter: George Gastaldi > Assignee: Michal Matloka > > There are cases where a version of a specific artifact is unknown during test execution. > Aether supports version ranging: > {code}org.sonatype.aether.RepositorySystem.resolveVersionRange(RepositorySystemSession, VersionRangeRequest){code} > It would be nice to provide an API in ShrinkWrap Resolver to: > - Resolve the available versions from a specific given range > - From that range, the possibility to retrieve the lowest and the highest version > - Reuse this information to resolve artifacts using the already existing ShrinkWrap Resolver APIs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-114) Support resolution of versions from a specific artifact

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-114?page=com.atlassian.jira.plu... ] Michal Matloka commented on SHRINKRES-114: ------------------------------------------ Version range requests returns versions info data, not dependencies. Forge team indicates that they would like to get those versions info to get further only e.g. highest version, without transferring all versions files. This probaby requieres some API additions e.g. * addition of resolveVersions method in ResolveStage * resolveVersions would return e.g. wrapped VersionRangeResult object providing getHighest etc methods converting aether Version e.g. to Maven Artifact Info Example: {code} final MavenArtifactInfo mavenArtifactInfo = Maven.resolver().resolveVersions("groupId:artifactId:[1.0,2.0)").getHighest(); {code} It is not a perfect solution yet, because then SWR has to be used second time to get real files. {code} Maven.resolver().resolve(mavenArtifactInfo.getCoordinate).with.... {code} > Support resolution of versions from a specific artifact > ------------------------------------------------------- > > Key: SHRINKRES-114 > URL: https://issues.jboss.org/browse/SHRINKRES-114 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-beta-2 > Reporter: George Gastaldi > Assignee: Michal Matloka > > There are cases where a version of a specific artifact is unknown during test execution. > Aether supports version ranging: > {code}org.sonatype.aether.RepositorySystem.resolveVersionRange(RepositorySystemSession, VersionRangeRequest){code} > It would be nice to provide an API in ShrinkWrap Resolver to: > - Resolve the available versions from a specific given range > - From that range, the possibility to retrieve the lowest and the highest version > - Reuse this information to resolve artifacts using the already existing ShrinkWrap Resolver APIs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-113) resolving of maven artifacts with classifier failed

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-113?page=com.atlassian.jira.plu... ] Michal Matloka updated SHRINKRES-113: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/shrinkwrap/resolver/pull/40 improved description > resolving of maven artifacts with classifier failed > --------------------------------------------------- > > Key: SHRINKRES-113 > URL: https://issues.jboss.org/browse/SHRINKRES-113 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: api-maven > Affects Versions: 2.0.0-beta-2 > Reporter: Juergen Biersack > Assignee: Michal Matloka > > The following code is not working: > {code:title=ArquillianTest.java|borderStyle=solid} > @Deployment > public static EnterpriseArchive createDeployment() { > ... > JavaArchive[] ejbModule = mavenResolver > .resolve("groupId:artifactId:jar:classifier") > .withoutTransitivity() > .as(JavaArchive.class); > ... > } > {code} > The class org.jboss.shrinkwrap.resolver.api.maven.coordinate.MavenCoordinates should be able to interprete the coordinate above with the documented pattern: > *<groupId>:<artifactId>[:<packagingType>[:<classifier>]][:<version>]* > It seems, that the classifier is interpreted as version. > The following workaround is running well: > {code:title=ArquillianTest.java|borderStyle=solid} > @Deployment > public static EnterpriseArchive createDeployment() { > ... > JavaArchive[] warDependenciesClientViews = mavenResolver > .addDependency( > MavenDependencies.createDependency( > MavenCoordinates.createCoordinate( > "groupId", > "artifactId", > null, > PackagingType.JAR, > "classifier"), > null, > false)) > .resolve() > .withoutTransitivity() > .as(JavaArchive.class); > ... > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-114) Support resolution of versions from a specific artifact

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-114?page=com.atlassian.jira.plu... ] Michal Matloka commented on SHRINKRES-114: ------------------------------------------ <ALR> http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html <ALR> That's the existing Maven syntax <ALR> So we could do in String canonical form: <ALR> groupId:artifactId:(1,1.0] <ALR> I bet this needs no API additions either <ALR> We'd just use the existing "version" fields we have <ALR> And could start supporting range syntax > Support resolution of versions from a specific artifact > ------------------------------------------------------- > > Key: SHRINKRES-114 > URL: https://issues.jboss.org/browse/SHRINKRES-114 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-beta-2 > Reporter: George Gastaldi > Assignee: Michal Matloka > > There are cases where a version of a specific artifact is unknown during test execution. > Aether supports version ranging: > {code}org.sonatype.aether.RepositorySystem.resolveVersionRange(RepositorySystemSession, VersionRangeRequest){code} > It would be nice to provide an API in ShrinkWrap Resolver to: > - Resolve the available versions from a specific given range > - From that range, the possibility to retrieve the lowest and the highest version > - Reuse this information to resolve artifacts using the already existing ShrinkWrap Resolver APIs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-114) Support resolution of versions from a specific artifact

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-114?page=com.atlassian.jira.plu... ] Andrew Rubinger commented on SHRINKRES-114: ------------------------------------------- Likely needs no API additions. Perhaps we could simply start to support version range syntax as defined by http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html in the existing String canonical form and "version" fields. > Support resolution of versions from a specific artifact > ------------------------------------------------------- > > Key: SHRINKRES-114 > URL: https://issues.jboss.org/browse/SHRINKRES-114 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-beta-2 > Reporter: George Gastaldi > Assignee: Michal Matloka > > There are cases where a version of a specific artifact is unknown during test execution. > Aether supports version ranging: > {code}org.sonatype.aether.RepositorySystem.resolveVersionRange(RepositorySystemSession, VersionRangeRequest){code} > It would be nice to provide an API in ShrinkWrap Resolver to: > - Resolve the available versions from a specific given range > - From that range, the possibility to retrieve the lowest and the highest version > - Reuse this information to resolve artifacts using the already existing ShrinkWrap Resolver APIs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues March 2013