[JBoss JIRA] (SHRINKWRAP-517) URLPackageScanner fails to close ZipFile and retains a Windows file lock
by Andrew Rubinger (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-517?page=com.atlassian.jira.pl... ]
Andrew Rubinger commented on SHRINKWRAP-517:
--------------------------------------------
I think we should use this issue as a forcing function for a new stream of breaking changes development on a ShrinkWrap major revision:
https://github.com/shrinkwrap/shrinkwrap/issues/104
This will introduce Closeable support into ClassLoaders by nature of moving to a JRE7+ runtime.
[~bmajsak] WDYT? We start cutting Alphas of the new stream (which can break between releases) and that can address this problem here?
> URLPackageScanner fails to close ZipFile and retains a Windows file lock
> ------------------------------------------------------------------------
>
> Key: SHRINKWRAP-517
> URL: https://issues.jboss.org/browse/SHRINKWRAP-517
> Project: ShrinkWrap
> Issue Type: Bug
> Components: impl-base
> Affects Versions: 1.2.6
> Reporter: Falko Modler
>
> The method {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handleArchiveByFile(File)}} creates a {{ZipFile}} but never closes it:
> {code:java}
> private void handleArchiveByFile(File file) throws IOException, ClassNotFoundException {
> try {
> log.fine("archive: " + file);
> ZipFile zip = new ZipFile(file);
> Enumeration<? extends ZipEntry> entries = zip.entries();
> while (entries.hasMoreElements()) {
> ZipEntry entry = entries.nextElement();
> String name = entry.getName();
> if (name.startsWith(prefix + packageNamePath) && name.endsWith(SUFFIX_CLASS)
> && (addRecursively || !name.substring((prefix + packageNamePath).length() + 1).contains("/"))) {
> String className = name.replace("/", ".").substring(prefix.length(), name.length() - SUFFIX_CLASS.length());
> foundClass(className, name );
> }
> }
> } catch (ZipException e) {
> throw new RuntimeException("Error handling file " + file, e);
> }
> }
> {code}
> Solution: Close {{zip}} in {{finally}}.
> I found this problem with the help of Eclipse (which showed warning "Resource leak: 'zip' is never closed") while analyzing [why three tests are unable to delete the test archive|https://github.com/shrinkwrap/shrinkwrap/pull/109#discussion_r125...].
> Besides the fix in {{URLPackageScanner}} we need one more change to enable the deletion of the test archive in those tests: All three tests create a cusom {{URLClassLoader}} but they never close it.
> Unfortunately, {{java.net.URLClassLoader.close()}} is a JDK7+ feature but the tests are executed with JDK5.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (SHRINKWRAP-517) URLPackageScanner fails to close ZipFile and retains a Windows file lock
by Falko Modler (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-517?page=com.atlassian.jira.pl... ]
Falko Modler commented on SHRINKWRAP-517:
-----------------------------------------
The only way I found to reproduce this problem is the way the three tests mentioned above are creating a {{Domain}} via a custom {{URLClassLoader}}.
In that scenario both the CL *and* the {{ZipFile}} in the Scanner have to be closed.
This means that:
- either I cannot provide a test because tests are executed with JDK5 and in that version {{URLClassLoader}} does not have a {{.close()}} method
- or I have to use an ugly hack like this one: https://stackoverflow.com/a/31114719 (which is probably Oracle/Sun JVM specific)
PS: There are at least two more tests creating an {{URLClassLoader}} but never closing it.
> URLPackageScanner fails to close ZipFile and retains a Windows file lock
> ------------------------------------------------------------------------
>
> Key: SHRINKWRAP-517
> URL: https://issues.jboss.org/browse/SHRINKWRAP-517
> Project: ShrinkWrap
> Issue Type: Bug
> Components: impl-base
> Affects Versions: 1.2.6
> Reporter: Falko Modler
>
> The method {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handleArchiveByFile(File)}} creates a {{ZipFile}} but never closes it:
> {code:java}
> private void handleArchiveByFile(File file) throws IOException, ClassNotFoundException {
> try {
> log.fine("archive: " + file);
> ZipFile zip = new ZipFile(file);
> Enumeration<? extends ZipEntry> entries = zip.entries();
> while (entries.hasMoreElements()) {
> ZipEntry entry = entries.nextElement();
> String name = entry.getName();
> if (name.startsWith(prefix + packageNamePath) && name.endsWith(SUFFIX_CLASS)
> && (addRecursively || !name.substring((prefix + packageNamePath).length() + 1).contains("/"))) {
> String className = name.replace("/", ".").substring(prefix.length(), name.length() - SUFFIX_CLASS.length());
> foundClass(className, name );
> }
> }
> } catch (ZipException e) {
> throw new RuntimeException("Error handling file " + file, e);
> }
> }
> {code}
> Solution: Close {{zip}} in {{finally}}.
> I found this problem with the help of Eclipse (which showed warning "Resource leak: 'zip' is never closed") while analyzing [why three tests are unable to delete the test archive|https://github.com/shrinkwrap/shrinkwrap/pull/109#discussion_r125...].
> Besides the fix in {{URLPackageScanner}} we need one more change to enable the deletion of the test archive in those tests: All three tests create a cusom {{URLClassLoader}} but they never close it.
> Unfortunately, {{java.net.URLClassLoader.close()}} is a JDK7+ feature but the tests are executed with JDK5.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (SHRINKWRAP-517) URLPackageScanner fails to close ZipFile and retains a Windows file lock
by Falko Modler (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-517?page=com.atlassian.jira.pl... ]
Falko Modler commented on SHRINKWRAP-517:
-----------------------------------------
[~bmajsak] WDYT about the JDK5 problem? Is it really necessary to retain Java5 compatibility? It's ancient, really.
It's also not very intuitive that in _some_ shrinkwrap modules tests are executed with another JDK than they were built with.
> URLPackageScanner fails to close ZipFile and retains a Windows file lock
> ------------------------------------------------------------------------
>
> Key: SHRINKWRAP-517
> URL: https://issues.jboss.org/browse/SHRINKWRAP-517
> Project: ShrinkWrap
> Issue Type: Bug
> Components: impl-base
> Affects Versions: 1.2.6
> Reporter: Falko Modler
>
> The method {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handleArchiveByFile(File)}} creates a {{ZipFile}} but never closes it:
> {code:java}
> private void handleArchiveByFile(File file) throws IOException, ClassNotFoundException {
> try {
> log.fine("archive: " + file);
> ZipFile zip = new ZipFile(file);
> Enumeration<? extends ZipEntry> entries = zip.entries();
> while (entries.hasMoreElements()) {
> ZipEntry entry = entries.nextElement();
> String name = entry.getName();
> if (name.startsWith(prefix + packageNamePath) && name.endsWith(SUFFIX_CLASS)
> && (addRecursively || !name.substring((prefix + packageNamePath).length() + 1).contains("/"))) {
> String className = name.replace("/", ".").substring(prefix.length(), name.length() - SUFFIX_CLASS.length());
> foundClass(className, name );
> }
> }
> } catch (ZipException e) {
> throw new RuntimeException("Error handling file " + file, e);
> }
> }
> {code}
> Solution: Close {{zip}} in {{finally}}.
> I found this problem with the help of Eclipse (which showed warning "Resource leak: 'zip' is never closed") while analyzing [why three tests are unable to delete the test archive|https://github.com/shrinkwrap/shrinkwrap/pull/109#discussion_r125...].
> Besides the fix in {{URLPackageScanner}} we need one more change to enable the deletion of the test archive in those tests: All three tests create a cusom {{URLClassLoader}} but they never close it.
> Unfortunately, {{java.net.URLClassLoader.close()}} is a JDK7+ feature but the tests are executed with JDK5.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (SHRINKWRAP-517) URLPackageScanner fails to close ZipFile and retains a Windows file lock
by Falko Modler (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-517?page=com.atlassian.jira.pl... ]
Falko Modler updated SHRINKWRAP-517:
------------------------------------
Description:
The method {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handleArchiveByFile(File)}} creates a {{ZipFile}} but never closes it:
{code:java}
private void handleArchiveByFile(File file) throws IOException, ClassNotFoundException {
try {
log.fine("archive: " + file);
ZipFile zip = new ZipFile(file);
Enumeration<? extends ZipEntry> entries = zip.entries();
while (entries.hasMoreElements()) {
ZipEntry entry = entries.nextElement();
String name = entry.getName();
if (name.startsWith(prefix + packageNamePath) && name.endsWith(SUFFIX_CLASS)
&& (addRecursively || !name.substring((prefix + packageNamePath).length() + 1).contains("/"))) {
String className = name.replace("/", ".").substring(prefix.length(), name.length() - SUFFIX_CLASS.length());
foundClass(className, name );
}
}
} catch (ZipException e) {
throw new RuntimeException("Error handling file " + file, e);
}
}
{code}
Solution: Close {{zip}} in {{finally}}.
I found this problem with the help of Eclipse (which showed warning "Resource leak: 'zip' is never closed") while analyzing [why three tests are unable to delete the test archive|https://github.com/shrinkwrap/shrinkwrap/pull/109#discussion_r125...].
Besides the fix in {{URLPackageScanner}} we need one more change to enable the deletion of the test archive in those tests: All three tests create a cusom {{URLClassLoader}} but they never close it.
Unfortunately, {{java.net.URLClassLoader.close()}} is a JDK7+ feature but the tests are executed with JDK5.
was:
The method {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handleArchiveByFile(File)}} creates a `ZipFile`but never closes it:
{code:java}
private void handleArchiveByFile(File file) throws IOException, ClassNotFoundException {
try {
log.fine("archive: " + file);
ZipFile zip = new ZipFile(file);
Enumeration<? extends ZipEntry> entries = zip.entries();
while (entries.hasMoreElements()) {
ZipEntry entry = entries.nextElement();
String name = entry.getName();
if (name.startsWith(prefix + packageNamePath) && name.endsWith(SUFFIX_CLASS)
&& (addRecursively || !name.substring((prefix + packageNamePath).length() + 1).contains("/"))) {
String className = name.replace("/", ".").substring(prefix.length(), name.length() - SUFFIX_CLASS.length());
foundClass(className, name );
}
}
} catch (ZipException e) {
throw new RuntimeException("Error handling file " + file, e);
}
}
{code}
Solution: Close `zip` in `finally`.
I found this problem with the help of Eclipse (which showed warning "Resource leak: 'zip' is never closed") while analyzing [why three tests are unable to delete the test archive|https://github.com/shrinkwrap/shrinkwrap/pull/109#discussion_r125...].
Besides the fix in {{URLPackageScanner}} we need one more change to enable the deletion of the test archive in those tests: All three tests create a cusom {{URLClassLoader}} but they never close it.
Unfortunately, {{java.net.URLClassLoader.close()}} is a JDK7+ feature but the tests are executed with JDK5.
> URLPackageScanner fails to close ZipFile and retains a Windows file lock
> ------------------------------------------------------------------------
>
> Key: SHRINKWRAP-517
> URL: https://issues.jboss.org/browse/SHRINKWRAP-517
> Project: ShrinkWrap
> Issue Type: Bug
> Components: impl-base
> Affects Versions: 1.2.6
> Reporter: Falko Modler
>
> The method {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handleArchiveByFile(File)}} creates a {{ZipFile}} but never closes it:
> {code:java}
> private void handleArchiveByFile(File file) throws IOException, ClassNotFoundException {
> try {
> log.fine("archive: " + file);
> ZipFile zip = new ZipFile(file);
> Enumeration<? extends ZipEntry> entries = zip.entries();
> while (entries.hasMoreElements()) {
> ZipEntry entry = entries.nextElement();
> String name = entry.getName();
> if (name.startsWith(prefix + packageNamePath) && name.endsWith(SUFFIX_CLASS)
> && (addRecursively || !name.substring((prefix + packageNamePath).length() + 1).contains("/"))) {
> String className = name.replace("/", ".").substring(prefix.length(), name.length() - SUFFIX_CLASS.length());
> foundClass(className, name );
> }
> }
> } catch (ZipException e) {
> throw new RuntimeException("Error handling file " + file, e);
> }
> }
> {code}
> Solution: Close {{zip}} in {{finally}}.
> I found this problem with the help of Eclipse (which showed warning "Resource leak: 'zip' is never closed") while analyzing [why three tests are unable to delete the test archive|https://github.com/shrinkwrap/shrinkwrap/pull/109#discussion_r125...].
> Besides the fix in {{URLPackageScanner}} we need one more change to enable the deletion of the test archive in those tests: All three tests create a cusom {{URLClassLoader}} but they never close it.
> Unfortunately, {{java.net.URLClassLoader.close()}} is a JDK7+ feature but the tests are executed with JDK5.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (SHRINKWRAP-517) URLPackageScanner fails to close ZipFile and retains a Windows file lock
by Falko Modler (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-517?page=com.atlassian.jira.pl... ]
Falko Modler updated SHRINKWRAP-517:
------------------------------------
Steps to Reproduce:
- execute one of the {{AddPackage*}} tests, e.g. {{AddPackageFromWarTestCase}} (see also SHRINKWRAP-515 (!))
- {{test[0-9]+.war}} will be left behind in {{target}}
- test output will contain a warning that the test archive could not be deleted
was:
- execute one of the {{AddPackage*}} tests, e.g. {{AddPackageFromWarTestCase}} (see also SHRINKWRAP-515 (!))
- `test[0-9]+.war` will be left behind in {{target}}
- test output will contain a warning that the test archive could not be deleted
> URLPackageScanner fails to close ZipFile and retains a Windows file lock
> ------------------------------------------------------------------------
>
> Key: SHRINKWRAP-517
> URL: https://issues.jboss.org/browse/SHRINKWRAP-517
> Project: ShrinkWrap
> Issue Type: Bug
> Components: impl-base
> Affects Versions: 1.2.6
> Reporter: Falko Modler
>
> The method {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handleArchiveByFile(File)}} creates a `ZipFile`but never closes it:
> {code:java}
> private void handleArchiveByFile(File file) throws IOException, ClassNotFoundException {
> try {
> log.fine("archive: " + file);
> ZipFile zip = new ZipFile(file);
> Enumeration<? extends ZipEntry> entries = zip.entries();
> while (entries.hasMoreElements()) {
> ZipEntry entry = entries.nextElement();
> String name = entry.getName();
> if (name.startsWith(prefix + packageNamePath) && name.endsWith(SUFFIX_CLASS)
> && (addRecursively || !name.substring((prefix + packageNamePath).length() + 1).contains("/"))) {
> String className = name.replace("/", ".").substring(prefix.length(), name.length() - SUFFIX_CLASS.length());
> foundClass(className, name );
> }
> }
> } catch (ZipException e) {
> throw new RuntimeException("Error handling file " + file, e);
> }
> }
> {code}
> Solution: Close `zip` in `finally`.
> I found this problem with the help of Eclipse (which showed warning "Resource leak: 'zip' is never closed") while analyzing [why three tests are unable to delete the test archive|https://github.com/shrinkwrap/shrinkwrap/pull/109#discussion_r125...].
> Besides the fix in {{URLPackageScanner}} we need one more change to enable the deletion of the test archive in those tests: All three tests create a cusom {{URLClassLoader}} but they never close it.
> Unfortunately, {{java.net.URLClassLoader.close()}} is a JDK7+ feature but the tests are executed with JDK5.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (SHRINKWRAP-517) URLPackageScanner fails to close ZipFile and retains a Windows file lock
by Falko Modler (JIRA)
Falko Modler created SHRINKWRAP-517:
---------------------------------------
Summary: URLPackageScanner fails to close ZipFile and retains a Windows file lock
Key: SHRINKWRAP-517
URL: https://issues.jboss.org/browse/SHRINKWRAP-517
Project: ShrinkWrap
Issue Type: Bug
Components: impl-base
Affects Versions: 1.2.6
Reporter: Falko Modler
The method {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handleArchiveByFile(File)}} creates a `ZipFile`but never closes it:
{code:java}
private void handleArchiveByFile(File file) throws IOException, ClassNotFoundException {
try {
log.fine("archive: " + file);
ZipFile zip = new ZipFile(file);
Enumeration<? extends ZipEntry> entries = zip.entries();
while (entries.hasMoreElements()) {
ZipEntry entry = entries.nextElement();
String name = entry.getName();
if (name.startsWith(prefix + packageNamePath) && name.endsWith(SUFFIX_CLASS)
&& (addRecursively || !name.substring((prefix + packageNamePath).length() + 1).contains("/"))) {
String className = name.replace("/", ".").substring(prefix.length(), name.length() - SUFFIX_CLASS.length());
foundClass(className, name );
}
}
} catch (ZipException e) {
throw new RuntimeException("Error handling file " + file, e);
}
}
{code}
Solution: Close `zip` in `finally`.
I found this problem with the help of Eclipse (which showed warning "Resource leak: 'zip' is never closed") while analyzing [why three tests are unable to delete the test archive|https://github.com/shrinkwrap/shrinkwrap/pull/109#discussion_r125...].
Besides the fix in {{URLPackageScanner}} we need one more change to enable the deletion of the test archive in those tests: All three tests create a cusom {{URLClassLoader}} but they never close it.
Unfortunately, {{java.net.URLClassLoader.close()}} is a JDK7+ feature but the tests are executed with JDK5.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (SHRINKWRAP-516) ContainerBase.addPackages() fails with IllegalArgumentException from ClassLoaderAsset
by Falko Modler (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-516?page=com.atlassian.jira.pl... ]
Falko Modler updated SHRINKWRAP-516:
------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/shrinkwrap/shrinkwrap/pull/110
PR sent.
> ContainerBase.addPackages() fails with IllegalArgumentException from ClassLoaderAsset
> -------------------------------------------------------------------------------------
>
> Key: SHRINKWRAP-516
> URL: https://issues.jboss.org/browse/SHRINKWRAP-516
> Project: ShrinkWrap
> Issue Type: Bug
> Components: impl-base
> Affects Versions: 1.2.4
> Reporter: Falko Modler
> Priority: Critical
>
> In my current JBoss EAP 6.4 project I tried to update Arquillian from 1.1.11 to 1.1.13 which fails with:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: /com/some_company/some_project/some_package/SomeClass.class not found in classloader sun.misc.Launcher$AppClassLoader@6bc7c054
> at org.jboss.shrinkwrap.api.asset.ClassLoaderAsset.<init>(ClassLoaderAsset.java:70)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.foundClass(URLPackageScanner.java:165)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:157)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:145)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.scanPackage(URLPackageScanner.java:113)
> at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addPackage(ContainerBase.java:1520)
> at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addPackages(ContainerBase.java:1485)
> at ...
> {noformat}
> Arquillian 1.1.13 brings in Shrinkwrap 1.2.6 (we are on 1.2.3 with Arquillian 1.1.11).
> After extensive research and debugging I am almost 100% sure that this is a regression caused by this commit (SHRINKWRAP-505):
> https://github.com/shrinkwrap/shrinkwrap/commit/d0df4ba3fd12998388521219e...
> The root cause of the problem lies within the {{else}} block of {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(File, String)}}:
> {code:java}
> private void handle(File file, String packageName) throws ClassNotFoundException {
> for (File child : file.listFiles()) {
> if (!child.isDirectory() && child.getName().endsWith(SUFFIX_CLASS)) {
> final String packagePrefix = packageName.length() > 0 ? packageName + "." : packageName;
> String className = packagePrefix + child.getName().substring(0, child.getName().lastIndexOf(SUFFIX_CLASS));
> foundClass(className, prefix + className.replace( '.', '/' ) + SUFFIX_CLASS );
> } else if (child.isDirectory() && addRecursively) {
> handle(child, packageName + "." + child.getName());
> }
> }
> }
> {code}
> The first {{handle()}} invocation has an _empty_ {{packageName}} and when the {{else}} block kicks in, {{handle()}} is called recursively with with e.g. ".com" which is a malformed package name.
> While SHRINKWRAP-505 did not touch this {{else}} block it _did_ remove a crucial {{.substring(1)}} call, see:
> https://github.com/shrinkwrap/shrinkwrap/commit/d0df4ba3fd12998388521219e...
> Suggested solution: Don't prepend a dot in case {{packageName}} is empty.
> Note: SHRINKWRAP-515 should be resolved alongside this fix as one of the affected tests was introduced in SHRINKWRAP-505.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (SHRINKWRAP-515) Building SHRINKWRAP: Some tests are never executed
by Falko Modler (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-515?page=com.atlassian.jira.pl... ]
Falko Modler updated SHRINKWRAP-515:
------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/shrinkwrap/shrinkwrap/pull/109
PR sent.
> Building SHRINKWRAP: Some tests are never executed
> --------------------------------------------------
>
> Key: SHRINKWRAP-515
> URL: https://issues.jboss.org/browse/SHRINKWRAP-515
> Project: ShrinkWrap
> Issue Type: Bug
> Components: impl-base
> Affects Versions: 1.2.6
> Reporter: Falko Modler
>
> The surefire configuration in the root {{pom.xml}} only includes:
> {code:xml}
> <includes>
> <include>**/*TestCase.java</include>
> <include>**/*TestSuite.java</include>
> </includes>
> {code}
> The following test classes do not adhere to this and are therefore never executed:
> {noformat}
> impl-base/src/test/java/org/jboss/shrinkwrap/impl/base/spec/AddPackageFromJarContainingWebInfTest.java
> impl-base/src/test/java/org/jboss/shrinkwrap/impl/base/spec/AddPackageFromWarTest.java
> impl-base/src/test/java/org/jboss/shrinkwrap/impl/base/spec/AddPackageFromWarWithNonRootClassloaderTest.java
> {noformat}
> I fixed the names locally but then execution of all three tests fails because these tests are using JDK7 classes but are executed with JDK5 (see surefire config in {{impl-base/pom.xml}}):
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.007 sec <<< FAILURE! - in org.jboss.shrinkwrap.impl.base.spec.AddPackageFromWarWithNonRootClassloaderTestCase
> initializationError(org.jboss.shrinkwrap.impl.base.spec.AddPackageFromWarWithNonRootClassloaderTestCase) Time elapsed: 0.006 sec <<< ERROR!
> java.lang.NoClassDefFoundError: Ljava/nio/file/Path;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2259)
> at java.lang.Class.getDeclaredFields(Class.java:1715)
> at org.junit.runners.model.TestClass.<init>(TestClass.java:42)
> at org.junit.runners.ParentRunner.<init>(ParentRunner.java:65)
> at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:58)
> at org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (SHRINKWRAP-516) ContainerBase.addPackages() fails with IllegalArgumentException from ClassLoaderAsset
by Falko Modler (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-516?page=com.atlassian.jira.pl... ]
Falko Modler updated SHRINKWRAP-516:
------------------------------------
Description:
In my current JBoss EAP 6.4 project I tried to update Arquillian from 1.1.11 to 1.1.13 which fails with:
{noformat}
Caused by: java.lang.IllegalArgumentException: /com/some_company/some_project/some_package/SomeClass.class not found in classloader sun.misc.Launcher$AppClassLoader@6bc7c054
at org.jboss.shrinkwrap.api.asset.ClassLoaderAsset.<init>(ClassLoaderAsset.java:70)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.foundClass(URLPackageScanner.java:165)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:157)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:145)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.scanPackage(URLPackageScanner.java:113)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addPackage(ContainerBase.java:1520)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addPackages(ContainerBase.java:1485)
at ...
{noformat}
Arquillian 1.1.13 brings in Shrinkwrap 1.2.6 (we are on 1.2.3 with Arquillian 1.1.11).
After extensive research and debugging I am almost 100% sure that this is a regression caused by this commit (SHRINKWRAP-505):
https://github.com/shrinkwrap/shrinkwrap/commit/d0df4ba3fd12998388521219e...
The root cause of the problem lies within the {{else}} block of {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(File, String)}}:
{code:java}
private void handle(File file, String packageName) throws ClassNotFoundException {
for (File child : file.listFiles()) {
if (!child.isDirectory() && child.getName().endsWith(SUFFIX_CLASS)) {
final String packagePrefix = packageName.length() > 0 ? packageName + "." : packageName;
String className = packagePrefix + child.getName().substring(0, child.getName().lastIndexOf(SUFFIX_CLASS));
foundClass(className, prefix + className.replace( '.', '/' ) + SUFFIX_CLASS );
} else if (child.isDirectory() && addRecursively) {
handle(child, packageName + "." + child.getName());
}
}
}
{code}
The first {{handle()}} invocation has an _empty_ {{packageName}} and when the {{else}} block kicks in, {{handle()}} is called recursively with with e.g. ".com" which is a malformed package name.
While SHRINKWRAP-505 did not touch this {{else}} block it _did_ remove a crucial {{.substring(1)}} call, see:
https://github.com/shrinkwrap/shrinkwrap/commit/d0df4ba3fd12998388521219e...
Suggested solution: Don't prepend a dot in case {{packageName}} is empty.
Note: SHRINKWRAP-515 should be resolved alongside this fix as one of the affected tests was introduced in SHRINKWRAP-505.
was:
In my current JBoss EAP 6.4 project I tried to update Arquillian from 1.1.11 to 1.1.13 which fails with:
{noformat}
Caused by: java.lang.IllegalArgumentException: /com/some_company/some_project/some_package/SomeClass.class not found in classloader sun.misc.Launcher$AppClassLoader@6bc7c054
at org.jboss.shrinkwrap.api.asset.ClassLoaderAsset.<init>(ClassLoaderAsset.java:70)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.foundClass(URLPackageScanner.java:165)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:157)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:145)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.scanPackage(URLPackageScanner.java:113)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addPackage(ContainerBase.java:1520)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addPackages(ContainerBase.java:1485)
at ...
{noformat}
Arquillian 1.1.13 brings in Shrinkwrap 1.2.6 (we are on 1.2.3 with Arquillian 1.1.11).
After extensive research and debugging I am almost 100% sure that this is a regression caused by this commit (SHRINKWRAP-505):
https://github.com/shrinkwrap/shrinkwrap/commit/d0df4ba3fd12998388521219e...
The root cause of the problem lies within the {{else}} block of {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(File, String)}}:
{code:java}
private void handle(File file, String packageName) throws ClassNotFoundException {
for (File child : file.listFiles()) {
if (!child.isDirectory() && child.getName().endsWith(SUFFIX_CLASS)) {
final String packagePrefix = packageName.length() > 0 ? packageName + "." : packageName;
String className = packagePrefix + child.getName().substring(0, child.getName().lastIndexOf(SUFFIX_CLASS));
foundClass(className, prefix + className.replace( '.', '/' ) + SUFFIX_CLASS );
} else if (child.isDirectory() && addRecursively) {
handle(child, packageName + "." + child.getName());
}
}
}
{code}
The first {{handle()}} invocation has an _empty_ {{packageName}} and when the {{else}} block kicks in, {{handle()}} is called recursively with with e.g. ".com" which is a malformed package name.
While SHRINKWRAP-505 did not touch this else block it _did_ remove a crucial {{.substring(1)}} call, see:
https://github.com/shrinkwrap/shrinkwrap/commit/d0df4ba3fd12998388521219e...
Suggested solution: Don't prepend a dot in case {{packageName}} is empty.
Note: SHRINKWRAP-515 should be resolved alongside this fix as one of the affected tests was introduced in SHRINKWRAP-505.
> ContainerBase.addPackages() fails with IllegalArgumentException from ClassLoaderAsset
> -------------------------------------------------------------------------------------
>
> Key: SHRINKWRAP-516
> URL: https://issues.jboss.org/browse/SHRINKWRAP-516
> Project: ShrinkWrap
> Issue Type: Bug
> Components: impl-base
> Affects Versions: 1.2.4
> Reporter: Falko Modler
> Priority: Critical
>
> In my current JBoss EAP 6.4 project I tried to update Arquillian from 1.1.11 to 1.1.13 which fails with:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: /com/some_company/some_project/some_package/SomeClass.class not found in classloader sun.misc.Launcher$AppClassLoader@6bc7c054
> at org.jboss.shrinkwrap.api.asset.ClassLoaderAsset.<init>(ClassLoaderAsset.java:70)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.foundClass(URLPackageScanner.java:165)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:157)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:145)
> at org.jboss.shrinkwrap.impl.base.URLPackageScanner.scanPackage(URLPackageScanner.java:113)
> at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addPackage(ContainerBase.java:1520)
> at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addPackages(ContainerBase.java:1485)
> at ...
> {noformat}
> Arquillian 1.1.13 brings in Shrinkwrap 1.2.6 (we are on 1.2.3 with Arquillian 1.1.11).
> After extensive research and debugging I am almost 100% sure that this is a regression caused by this commit (SHRINKWRAP-505):
> https://github.com/shrinkwrap/shrinkwrap/commit/d0df4ba3fd12998388521219e...
> The root cause of the problem lies within the {{else}} block of {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(File, String)}}:
> {code:java}
> private void handle(File file, String packageName) throws ClassNotFoundException {
> for (File child : file.listFiles()) {
> if (!child.isDirectory() && child.getName().endsWith(SUFFIX_CLASS)) {
> final String packagePrefix = packageName.length() > 0 ? packageName + "." : packageName;
> String className = packagePrefix + child.getName().substring(0, child.getName().lastIndexOf(SUFFIX_CLASS));
> foundClass(className, prefix + className.replace( '.', '/' ) + SUFFIX_CLASS );
> } else if (child.isDirectory() && addRecursively) {
> handle(child, packageName + "." + child.getName());
> }
> }
> }
> {code}
> The first {{handle()}} invocation has an _empty_ {{packageName}} and when the {{else}} block kicks in, {{handle()}} is called recursively with with e.g. ".com" which is a malformed package name.
> While SHRINKWRAP-505 did not touch this {{else}} block it _did_ remove a crucial {{.substring(1)}} call, see:
> https://github.com/shrinkwrap/shrinkwrap/commit/d0df4ba3fd12998388521219e...
> Suggested solution: Don't prepend a dot in case {{packageName}} is empty.
> Note: SHRINKWRAP-515 should be resolved alongside this fix as one of the affected tests was introduced in SHRINKWRAP-505.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[JBoss JIRA] (SHRINKWRAP-516) ContainerBase.addPackages() fails with IllegalArgumentException from ClassLoaderAsset
by Falko Modler (JIRA)
Falko Modler created SHRINKWRAP-516:
---------------------------------------
Summary: ContainerBase.addPackages() fails with IllegalArgumentException from ClassLoaderAsset
Key: SHRINKWRAP-516
URL: https://issues.jboss.org/browse/SHRINKWRAP-516
Project: ShrinkWrap
Issue Type: Bug
Components: impl-base
Affects Versions: 1.2.4
Reporter: Falko Modler
Priority: Critical
In my current JBoss EAP 6.4 project I tried to update Arquillian from 1.1.11 to 1.1.13 which fails with:
{noformat}
Caused by: java.lang.IllegalArgumentException: /com/some_company/some_project/some_package/SomeClass.class not found in classloader sun.misc.Launcher$AppClassLoader@6bc7c054
at org.jboss.shrinkwrap.api.asset.ClassLoaderAsset.<init>(ClassLoaderAsset.java:70)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.foundClass(URLPackageScanner.java:165)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:157)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:159)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:145)
at org.jboss.shrinkwrap.impl.base.URLPackageScanner.scanPackage(URLPackageScanner.java:113)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addPackage(ContainerBase.java:1520)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addPackages(ContainerBase.java:1485)
at ...
{noformat}
Arquillian 1.1.13 brings in Shrinkwrap 1.2.6 (we are on 1.2.3 with Arquillian 1.1.11).
After extensive research and debugging I am almost 100% sure that this is a regression caused by this commit (SHRINKWRAP-505):
https://github.com/shrinkwrap/shrinkwrap/commit/d0df4ba3fd12998388521219e...
The root cause of the problem lies within the {{else}} block of {{org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(File, String)}}:
{code:java}
private void handle(File file, String packageName) throws ClassNotFoundException {
for (File child : file.listFiles()) {
if (!child.isDirectory() && child.getName().endsWith(SUFFIX_CLASS)) {
final String packagePrefix = packageName.length() > 0 ? packageName + "." : packageName;
String className = packagePrefix + child.getName().substring(0, child.getName().lastIndexOf(SUFFIX_CLASS));
foundClass(className, prefix + className.replace( '.', '/' ) + SUFFIX_CLASS );
} else if (child.isDirectory() && addRecursively) {
handle(child, packageName + "." + child.getName());
}
}
}
{code}
The first {{handle()}} invocation has an _empty_ {{packageName}} and when the {{else}} block kicks in, {{handle()}} is called recursively with with e.g. ".com" which is a malformed package name.
While SHRINKWRAP-505 did not touch this else block it _did_ remove a crucial {{.substring(1)}} call, see:
https://github.com/shrinkwrap/shrinkwrap/commit/d0df4ba3fd12998388521219e...
Suggested solution: Don't prepend a dot in case {{packageName}} is empty.
Note: SHRINKWRAP-515 should be resolved alongside this fix as one of the affected tests was introduced in SHRINKWRAP-505.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months