July 2012 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKDESC-121) WebFragmentDescriptor defaultFileName should be web-fragment.xml

by Aslak Knutsen (JIRA)

Aslak Knutsen created SHRINKDESC-121: ---------------------------------------- Summary: WebFragmentDescriptor defaultFileName should be web-fragment.xml Key: SHRINKDESC-121 URL: https://issues.jboss.org/browse/SHRINKDESC-121 Project: ShrinkWrap Descriptors Issue Type: Bug Components: impl-javaee Affects Versions: 2.0.0-alpha-2 Reporter: Aslak Knutsen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

2
2
0 / 0

[JBoss JIRA] (SHRINKWRAP-398) Descriptors 2.0 module creates duplicate <alternatives/> entries (test case attached)

by Craig Ringer (JIRA)

Craig Ringer created SHRINKWRAP-398: --------------------------------------- Summary: Descriptors 2.0 module creates duplicate <alternatives/> entries (test case attached) Key: SHRINKWRAP-398 URL: https://issues.jboss.org/browse/SHRINKWRAP-398 Project: ShrinkWrap Issue Type: Bug Components: ext-descriptors Affects Versions: 1.0.0 Environment: java version "1.7.0_01" Java(TM) SE Runtime Environment (build 1.7.0_01-b08) Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode) Linux ayaki.localdomain 3.3.0-4.fc16.x86_64 #1 SMP Tue Mar 20 18:05:40 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Reporter: Craig Ringer Attachments: ArquillianShrinkwrapDuplicateAlternatives.zip Using: org.jboss.shrinkwrap.descriptors:shrinkwrap-descriptors-impl-javaee:jar:2.0.0-alpha-2 The attached test case produces an invalid beans.xml with a duplicate <alternatives/> entry with the code: BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class) .from(new File("src/main/webapp/WEB-INF/beans.xml")) .getOrCreateAlternatives(); 'getOrCreate' is in fact always creating an alternatives entry. Also: Since there can only ever be one <alternatives/> block, it's not clear what the difference between getOrCreateAlternatives() and createAlternatives() is. Is the latter supposed to *replace* any existing block? The API for managing alternatives is in Descriptors 2.0 is IMO difficult to use and understand. Issues with examples pending. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

3
9
0 / 0

[JBoss JIRA] (SHRINKDESC-129) Create new module for Ant Metadata Parser

by Andrew Rubinger (JIRA)

Andrew Rubinger created SHRINKDESC-129: ------------------------------------------ Summary: Create new module for Ant Metadata Parser Key: SHRINKDESC-129 URL: https://issues.jboss.org/browse/SHRINKDESC-129 Project: ShrinkWrap Descriptors Issue Type: Feature Request Reporter: Andrew Rubinger Assignee: Ralf Battenfeld We really don't need the Ant libraries in metadata-parser; make an extension module for Ant support and move SHRINKDESC-122 into it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

2
3
0 / 0

[JBoss JIRA] (SHRINKDESC-128) Missing attributes

by Jesper Pedersen (JIRA)

Jesper Pedersen created SHRINKDESC-128: ------------------------------------------ Summary: Missing attributes Key: SHRINKDESC-128 URL: https://issues.jboss.org/browse/SHRINKDESC-128 Project: ShrinkWrap Descriptors Issue Type: Bug Components: metadata-parser Affects Versions: 2.0.0-alpha-3 Reporter: Jesper Pedersen Assignee: Ralf Battenfeld Fix For: 2.0.0-alpha-4 The connector XSD defines {noformat} <xsd:complexType name="config-propertyType"> <xsd:sequence> <xsd:element name="description" type="j2ee:descriptionType" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="config-property-name" type="j2ee:config-property-nameType"/> <xsd:element name="config-property-type" type="j2ee:config-property-typeType"/> <xsd:element name="config-property-value" type="j2ee:xsdStringType" minOccurs="0"> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID"/> </xsd:complexType> {noformat} However, the metadata parser doesn't generate methods to allow access to "id" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

3
5
0 / 0

[JBoss JIRA] (SHRINKDESC-118) Fix Jetty7TestCase So It Doesn't Require Network Connection and Access to www.eclipse.org

by Andrew Rubinger (JIRA)

Andrew Rubinger created SHRINKDESC-118: ------------------------------------------ Summary: Fix Jetty7TestCase So It Doesn't Require Network Connection and Access to www.eclipse.org Key: SHRINKDESC-118 URL: https://issues.jboss.org/browse/SHRINKDESC-118 Project: ShrinkWrap Descriptors Issue Type: Task Reporter: Andrew Rubinger Priority: Minor {code}java.lang.RuntimeException: java.net.UnknownHostException: www.eclipse.org at org.jboss.shrinkwrap.descriptor.test.util.XmlAssert.assertIdentical(XmlAssert.java:212) at org.jboss.shrinkwrap.descriptor.test.jetty7.Jetty7TestCase.testJettyConfiguration(Jetty7TestCase.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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) 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.net.UnknownHostException: www.eclipse.org at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:195) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:529) at java.net.Socket.connect(Socket.java:478) at sun.net.NetworkClient.doConnect(NetworkClient.java:163) at sun.net.www.http.HttpClient.openServer(HttpClient.java:395) at sun.net.www.http.HttpClient.openServer(HttpClient.java:530) at sun.net.www.http.HttpClient.<init>(HttpClient.java:234) at sun.net.www.http.HttpClient.New(HttpClient.java:307) at sun.net.www.http.HttpClient.New(HttpClient.java:324) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:970) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:911) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:836) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:677) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1315) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:1282) at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:283) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(XMLDocumentScannerImpl.java:1194) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(XMLDocumentScannerImpl.java:1090) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1003) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:235) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:284) at org.custommonkey.xmlunit.XMLUnit.buildDocument(XMLUnit.java:383) at org.custommonkey.xmlunit.XMLUnit.buildDocument(XMLUnit.java:370) at org.custommonkey.xmlunit.Diff.<init>(Diff.java:101) at org.custommonkey.xmlunit.Diff.<init>(Diff.java:93) at org.jboss.shrinkwrap.descriptor.test.util.XmlAssert.assertIdentical(XmlAssert.java:202) ... 23 more{code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
2
0 / 0

[JBoss JIRA] (SHRINKWRAP-411) API inconsistency - allow to delete Class or Package from the Archive

by Piotr Nowicki (JIRA)

11 years, 9 months

4
8
0 / 0

[JBoss JIRA] (SHRINKWRAP-407) Archive.toString might throw java.lang.IndexOutOfBoundsException

by Tommy Tynjä (JIRA)

Tommy Tynjä created SHRINKWRAP-407: -------------------------------------- Summary: Archive.toString might throw java.lang.IndexOutOfBoundsException Key: SHRINKWRAP-407 URL: https://issues.jboss.org/browse/SHRINKWRAP-407 Project: ShrinkWrap Issue Type: Bug Components: impl-base Affects Versions: 1.1.0-alpha-2 Reporter: Tommy Tynjä Assignee: Tommy Tynjä In some cases when outputting archive contents via the Archive.toString(Formatter) method, I get a java.lang.IndexOutOfBoundsException when writing to the output stream. After some investigation I found the cause being an erroneous calculation in the buffered write. The error can be reproduced with the following test case added to ArchiveWriteToTestCase in impl-base: {code:java} @Test public void shouldBufferWritesCorrectly() throws IOException { MockOutputStream outputStream = new MockOutputStream(); byte[] content = new byte[9202]; for (int i = 0; i < content.length; i++) { content[i] = (i + "").getBytes()[0]; } IOUtil.bufferedWriteWithFlush(outputStream, content); Assert.assertArrayEquals("Inconsistent writes?", content, outputStream.getContents()); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

2
4
0 / 0

[JBoss JIRA] (SHRINKWRAP-413) Create a UUID for Archives

by Andrew Rubinger (JIRA)

Andrew Rubinger created SHRINKWRAP-413: ------------------------------------------ Summary: Create a UUID for Archives Key: SHRINKWRAP-413 URL: https://issues.jboss.org/browse/SHRINKWRAP-413 Project: ShrinkWrap Issue Type: Feature Request Reporter: Andrew Rubinger Assignee: Andrew Rubinger Demanded by the URI mechanism in NIO.2 FileSystems, we need a way to uniquely identify ShrinkWrap archives such that URIs are guaranteed to point to the correct space. Names are not unique. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
2
0 / 0

[JBoss JIRA] (SHRINKWRAP-377) ZipExporter.exportTo(java.io.File target) does not fail when target exists.

by Dominik Pospisil (Created) (JIRA)

ZipExporter.exportTo(java.io.File target) does not fail when target exists. --------------------------------------------------------------------------- Key: SHRINKWRAP-377 URL: https://issues.jboss.org/browse/SHRINKWRAP-377 Project: ShrinkWrap Issue Type: Bug Affects Versions: 1.0.0-cr-1 Reporter: Dominik Pospisil According to javadoc ZipExporter.exportTo(java.io.File target) should fail if the target file exists. It does not seem to be the case, the target file is rewritten silently instead. Also, the javadoc is confusing. It says: Exports provided archive as in an implementation-specific format, written to the specified File target. If the target exists this call will fail with IllegalArgumentException. However later it says that FileExistsException is thrown in such case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

3
9
0 / 0

[JBoss JIRA] (SHRINKDESC-126) JavaDoc incorrect for parameters

by Jesper Pedersen (JIRA)

Jesper Pedersen created SHRINKDESC-126: ------------------------------------------ Summary: JavaDoc incorrect for parameters Key: SHRINKDESC-126 URL: https://issues.jboss.org/browse/SHRINKDESC-126 Project: ShrinkWrap Descriptors Issue Type: Bug Components: metadata-parser Affects Versions: 2.0.0-alpha-3 Reporter: Jesper Pedersen Assignee: Ralf Battenfeld Fix For: 2.0.0-alpha-4 The generated .java files from the metadata-parser gives: {noformat} [javadoc] /xyz/build/embedded/src/main/java/org/jboss/jca/embedded/dsl/datasources11/impl/ConfigPropertyTypeImpl.java:58: warning - @param argument "configPropertyType" is not a parameter name. {noformat} for {noformat} /** * Sets the body text for the element <code>config-propertyType</code> * @param configPropertyType the value for the body text <code>config-propertyType</code> * @return the current instance of <code>ConfigPropertyType<T></code> */ public ConfigPropertyType<T> text(String value) { childNode.text(value); return this; } {noformat} It should be 'value' instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues July 2012