April 2011 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] Created: (SHRINKWRAP-88) Look at Import/Export API methods for consistency/convenience

by Aslak (JIRA)

Look at Import/Export API methods for consistency/convenience ------------------------------------------------------------- Key: SHRINKWRAP-88 URL: https://jira.jboss.org/jira/browse/SHRINKWRAP-88 Project: ShrinkWrap Issue Type: Task Components: api, impl-base Reporter: Aslak make import/export api naming/arguments equalequal import(url|file|resource) export(url|file) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

4
7
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-110) Code Review and Action Items on ExtensionLoader/ServiceExtensionLoader

by Andrew Lee Rubinger (JIRA)

Code Review and Action Items on ExtensionLoader/ServiceExtensionLoader ---------------------------------------------------------------------- Key: SHRINKWRAP-110 URL: https://jira.jboss.org/jira/browse/SHRINKWRAP-110 Project: ShrinkWrap Issue Type: Task Components: api, impl-base Reporter: Andrew Lee Rubinger We should do a community review on the ExtensionLoader API and ServiceExtensionLoader implementation. This is the mechanism used to power Assignable.as(); * Archives API should not expose extension loading configuration (SHRINKWRAP-102) * ServiceExtensionLoader needs documentation at class-level and on methods * ServiceExtensionLoader is not Thread-safe (or documented that this is the responsibility of the client, ArchiveBase, which does not sync access) * OK to always use TCCL at time of instantiation to find extension impls and classes? * ServiceExtensionLoader instance needs to be carried in the state of every archive? Should some Assignable types be given access to different service extension loaders? To me this looks like a singular point of configuration possibly warranting use of a Singleton. * All extension loading as a feature needs Wiki documentation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-175) Review Filter usage in API for consistency and applicability

by Andrew Lee Rubinger (JIRA)

Review Filter usage in API for consistency and applicability ------------------------------------------------------------ Key: SHRINKWRAP-175 URL: https://jira.jboss.org/browse/SHRINKWRAP-175 Project: ShrinkWrap Issue Type: Task Components: api Reporter: Andrew Lee Rubinger Fix For: 1.0.0-beta-1 Usage of "Filter" is currently sprinkled about inconsistenty. Ensure it's applied on all multi-* operations (like ClassContainer.addClasses) and its JavaDoc is updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
4
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-172) Clean up API

by Andrew Lee Rubinger (JIRA)

Clean up API ------------ Key: SHRINKWRAP-172 URL: https://jira.jboss.org/browse/SHRINKWRAP-172 Project: ShrinkWrap Issue Type: Task Components: api Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: 1.0.0-beta-1 Container task for minor API changes needed before we can lock to backwards-compat in 1.0.0-beta-1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-245) Evaluate the need for EnterpriseArchive.addApplicationResource

by Aslak Knutsen (JIRA)

Evaluate the need for EnterpriseArchive.addApplicationResource -------------------------------------------------------------- Key: SHRINKWRAP-245 URL: https://jira.jboss.org/browse/SHRINKWRAP-245 Project: ShrinkWrap Issue Type: Feature Request Components: api, impl-base Affects Versions: 1.0.0-alpha-11 Reporter: Aslak Knutsen EnterpriseArchive has it's own set of addApplicationResource methods, but compared to WebArchive, applicationResources and the ResourceContainer is mapped to the same location. Is the addApplicationResources methods needed at all? Should they simply be replaced by what is allready on the ResourceContainer. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
4
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-242) Get shrinkwrap to work from inside and OSGi framework

by David Bosschaert (JIRA)

Get shrinkwrap to work from inside and OSGi framework ----------------------------------------------------- Key: SHRINKWRAP-242 URL: https://jira.jboss.org/browse/SHRINKWRAP-242 Project: ShrinkWrap Issue Type: Task Affects Versions: 1.0.0-alpha-11 Reporter: David Bosschaert Assignee: David Bosschaert Currently there are issues around the use of Shrinkwrap in an OSGi framework. The libraries don't contain the necessary Manifest headers and just adding them causes classloading problems as the TCCL is used during the boot process. Shrinkwrap should be usable from within OSGi. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
31
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-274) Set release cycle to 1.0.0-beta-1

by Andrew Rubinger (JIRA)

Set release cycle to 1.0.0-beta-1 --------------------------------- Key: SHRINKWRAP-274 URL: https://issues.jboss.org/browse/SHRINKWRAP-274 Project: ShrinkWrap Issue Type: Task Reporter: Andrew Rubinger Assignee: Andrew Rubinger Fix For: 1.0.0-beta-1 Update POMs -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
1
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-246) Shrinkwrap does not work in a modular environment

by David Bosschaert (JIRA)

Shrinkwrap does not work in a modular environment ------------------------------------------------- Key: SHRINKWRAP-246 URL: https://issues.jboss.org/browse/SHRINKWRAP-246 Project: ShrinkWrap Issue Type: Bug Components: impl-base Reporter: David Bosschaert The Shrinkwrap static API to create and interact with Archives often makes use of the ThreadContextClassLoader which is problematic in a modular environment such as JBoss Modules and OSGi. Shrinkwrap should be made more friendly toward systems that use a classloader per module. For more background, see this email thread: http://lists.jboss.org/pipermail/jboss-as7-dev/2010-December/000122.html -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
5
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-244) When calling JavaArchiveImpl.addClass(String, ClassLoader) the TCCL gets used instead

by David Bosschaert (JIRA)

When calling JavaArchiveImpl.addClass(String, ClassLoader) the TCCL gets used instead ------------------------------------------------------------------------------------- Key: SHRINKWRAP-244 URL: https://jira.jboss.org/browse/SHRINKWRAP-244 Project: ShrinkWrap Issue Type: Bug Components: impl-base Affects Versions: 1.0.0-alpha-12 Reporter: David Bosschaert When I call JavaArchiveImpl.addClass(String fqcn, ClassLoader cl) the cl gets used to load fqcn, but then further down the line, I find myself in ContainerBase.addPackages(), which is called indirectly from the previous addClass method. The addPackages still uses the TCCL while it should really use the cl passed in to the addClass method. This also applies to JavaArchiveImpl.addClass(Class cls) where the classloader to be used could be inferred from the cls argument, but instead the TCCL gets used... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

3
10
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-269) Shrinkwrap is hanging

by Carlo de Wolf (JIRA)

Shrinkwrap is hanging --------------------- Key: SHRINKWRAP-269 URL: https://issues.jboss.org/browse/SHRINKWRAP-269 Project: ShrinkWrap Issue Type: Bug Environment: org.jboss.as.testsuite.integration.jaxrs.servletintegration.ApplicationPathOverrideIntegrationTestCase Reporter: Carlo de Wolf {noformat} $ jstack 3994 2011-04-01 21:59:20 Full thread dump Java HotSpot(TM) Server VM (19.0-b09 mixed mode): "Attach Listener" daemon prio=10 tid=0x8e11c400 nid=0x109a waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE "pool-2-thread-1" prio=10 tid=0xb6af5400 nid=0xfbd in Object.wait() [0x8d8fe000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xa997c858> (a org.jboss.shrinkwrap.impl.base.exporter.FutureCompletionInputStream) at java.io.PipedInputStream.awaitSpace(PipedInputStream.java:257) at java.io.PipedInputStream.receive(PipedInputStream.java:215) - locked <0xa997c858> (a org.jboss.shrinkwrap.impl.base.exporter.FutureCompletionInputStream) at java.io.PipedOutputStream.write(PipedOutputStream.java:132) at java.util.zip.ZipOutputStream.writeBytes(ZipOutputStream.java:456) at java.util.zip.ZipOutputStream.writeLOC(ZipOutputStream.java:351) at java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:179) at org.jboss.shrinkwrap.impl.base.exporter.JdkZipExporterDelegate$2.execute(JdkZipExporterDelegate.java:285) at org.jboss.shrinkwrap.impl.base.exporter.JdkZipExporterDelegate$2.execute(JdkZipExporterDelegate.java:262) at org.jboss.shrinkwrap.impl.base.io.IOUtil.closeOnComplete(IOUtil.java:227) at org.jboss.shrinkwrap.impl.base.exporter.JdkZipExporterDelegate.processNode(JdkZipExporterDelegate.java:261) at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:98) at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:103) at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:103) at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:103) at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:103) at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:103) at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:103) at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:103) at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:103) at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.export(AbstractExporterDelegate.java:88) at org.jboss.shrinkwrap.impl.base.exporter.JdkZipExporterDelegate.access$001(JdkZipExporterDelegate.java:55) at org.jboss.shrinkwrap.impl.base.exporter.JdkZipExporterDelegate$1.call(JdkZipExporterDelegate.java:134) at org.jboss.shrinkwrap.impl.base.exporter.JdkZipExporterDelegate$1.call(JdkZipExporterDelegate.java:127) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) "Thread-1" prio=10 tid=0x8dcb1400 nid=0xfac runnable [0x8da5c000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:199) at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) at java.io.BufferedInputStream.read(BufferedInputStream.java:317) - locked <0xaaa88b90> (a java.io.BufferedInputStream) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) - locked <0xaaa88ce0> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.Reader.read(Reader.java:123) at org.jboss.as.arquillian.container.managed.JBossAsManagedContainer$ConsoleConsumer.run(JBossAsManagedContainer.java:188) at java.lang.Thread.run(Thread.java:662) "process reaper" daemon prio=10 tid=0x8dcfe000 nid=0xfaa runnable [0x8daad000] java.lang.Thread.State: RUNNABLE at java.lang.UNIXProcess.waitForProcessExit(Native Method) at java.lang.UNIXProcess.access$900(UNIXProcess.java:20) at java.lang.UNIXProcess$1$1.run(UNIXProcess.java:132) "Low Memory Detector" daemon prio=10 tid=0xb6a99400 nid=0xfa5 runnable [0x00000000] java.lang.Thread.State: RUNNABLE "CompilerThread1" daemon prio=10 tid=0xb6a97800 nid=0xfa4 waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE "CompilerThread0" daemon prio=10 tid=0xb6a95800 nid=0xfa3 waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=10 tid=0xb6a93c00 nid=0xfa2 runnable [0x00000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=10 tid=0xb6a84400 nid=0xfa1 in Object.wait() [0x8f167000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xaaa893e8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked <0xaaa893e8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0xb6a82c00 nid=0xfa0 in Object.wait() [0x8f47d000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xaaa89478> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0xaaa89478> (a java.lang.ref.Reference$Lock) "main" prio=10 tid=0xb6a04c00 nid=0xf9c in Object.wait() [0xb6bf7000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xa9a90b70> (a org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager$Handler) at java.lang.Object.wait(Object.java:485) at org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager$Handler.get(ModelControllerClientServerDeploymentManager.java:164) - locked <0xa9a90b70> (a org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager$Handler) at org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager$Handler.get(ModelControllerClientServerDeploymentManager.java:64) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:68) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:41) at org.jboss.as.arquillian.container.AbstractDeployableContainer.executeDeploymentPlan(AbstractDeployableContainer.java:180) at org.jboss.as.arquillian.container.AbstractDeployableContainer.deploy(AbstractDeployableContainer.java:98) at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:62) at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:50) at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:99) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:165) at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:189) at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:300) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:185) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:128) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102) at org.apache.maven.surefire.Surefire.run(Surefire.java:180) 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) "VM Thread" prio=10 tid=0xb6a80400 nid=0xf9f runnable "GC task thread#0 (ParallelGC)" prio=10 tid=0xb6a0bc00 nid=0xf9d runnable "GC task thread#1 (ParallelGC)" prio=10 tid=0xb6a0d400 nid=0xf9e runnable "VM Periodic Task Thread" prio=10 tid=0xb6a9ac00 nid=0xfa6 waiting on condition JNI global references: 954 {noformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
13
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues April 2011