We're updating the issue view to help you get more done. 

Adding JBBC driver to EAR classpath fails with java.lang.NegativeArraySizeException on JBoss71x

Description

Here's the stacktrace:

1 2 3 4 5 6 7 8 9 10 11 12 13 java.lang.NegativeArraySizeException at org.codehaus.cargo.container.jboss.JBoss7xInstalledLocalDeployer.modifyManifestForClasspathEntries(JBoss7xInstalledLocalDeployer.java:183) at org.codehaus.cargo.container.jboss.JBoss7xInstalledLocalDeployer.doDeploy(JBoss7xInstalledLocalDeployer.java:89) at org.codehaus.cargo.container.spi.deployer.AbstractCopyingInstalledLocalDeployer.deploy(AbstractCopyingInstalledLocalDeployer.java:146) at org.codehaus.cargo.container.spi.deployer.AbstractDeployer.deploy(AbstractDeployer.java:54) at org.codehaus.cargo.container.jboss.JBoss7xStandaloneLocalConfiguration.doConfigure(JBoss7xStandaloneLocalConfiguration.java:401) at org.codehaus.cargo.container.jboss.JBoss71xStandaloneLocalConfiguration.doConfigure(JBoss71xStandaloneLocalConfiguration.java:117) at org.codehaus.cargo.container.spi.configuration.AbstractLocalConfiguration.configure(AbstractLocalConfiguration.java:263) at org.codehaus.cargo.container.jboss.JBoss7xStandaloneLocalConfiguration.configure(JBoss7xStandaloneLocalConfiguration.java:157) at org.codehaus.cargo.container.jboss.JBoss71xStandaloneLocalConfiguration.configure(JBoss71xStandaloneLocalConfiguration.java:77) at org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:199) at org.codehaus.cargo.daemon.CargoDaemonServlet.startContainer(CargoDaemonServlet.java:590) at org.codehaus.cargo.daemon.CargoDaemonServlet.service(CargoDaemonServlet.java:265)

I was able to find the cause: http://docs.oracle.com/javase/7/docs/api/java/util/zip/ZipEntry.html#getSize() may return -1 when size of the entry is not known. For some reason, in my environment -1 is returned, despite the fact that EAR file in question is valid, and I can see entry sizes correctly reported when using unzip -l in console.

Luckily the issue is easy to fix by eliminating the intermediate buffer into which the manifest data were loaded in the existing implementation and pass the ZipInputStraem into Manifest constructor directly.

After applying the attached patch manifest rewriting proceeds correctly and application (and it's associated driver and datasource) are deployed successfuly.

Status

Assignee

Savas Ali Tokmen

Reporter

Rafal Krzewski

Components

Fix versions

Affects versions

1.4.6

Priority

Major