ASF subversion and git services commented on GEODE-800:

Commit 68deb0db9578434e9043d56cc48ae1fae4166c5d in geode's branch 
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=68deb0d ]

GEODE-800: Update fast-classpath-scanner to 2.18.1 (#1430)

- This also fixes the issue of picking up nested resources
- The new fast-classpath-scanner runs slower than the prior version. This isn't
  a problem for general use, but some tests have been adjusted to take this
  into account.

> Geode's classloading mechanism is unable to resolve classes found within 
> nested jars
> ------------------------------------------------------------------------------------
>                 Key: GEODE-800
>                 URL: https://issues.apache.org/jira/browse/GEODE-800
>             Project: Geode
>          Issue Type: Bug
>          Components: configuration, gfsh
>    Affects Versions: 1.0.0-incubating
>            Reporter: Jens Deppe
>            Priority: Major
>              Labels: ClassLoader, DeployCommand, deploy, gfsh, 
> pull-request-available
>             Fix For: 1.5.0
>         Attachments: geode-800-testcase.zip
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
> This issue is particularly evident when using Geode in a Spring Boot app 
> which creates an '├╝ber' jar containing all dependent jars.
> When Geode is launched in this context, the following errors can be seen:
> {noformat}
> [warn 2016/01/20 08:53:29.431 PST <main> tid=0xd] (tid=13 msgId=0) Required 
> Commands classes were not loaded. Check logs for errors.
> java.lang.IllegalStateException: Required Commands classes were not loaded. 
> Check logs for errors.
>         at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.raiseExceptionIfEmpty(CommandManager.java:249)
>         at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.loadCommands(CommandManager.java:188)
>         at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.<init>(CommandManager.java:86)
>         at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.getInstance(CommandManager.java:278)
>         at 
> com.gemstone.gemfire.management.internal.cli.CommandManager.getInstance(CommandManager.java:258)
>         at 
> com.gemstone.gemfire.management.internal.cli.remote.CommandProcessor.<init>(CommandProcessor.java:58)
>         ...
> {noformat}
> The problem here is in {{ClasspathScanLoadHelper.getClasses()}}. In this 
> method we call:
> {noformat}
> Enumeration<URL> resources = 
> ClassPathLoader.getLatest().getResources(packagePath);
> {noformat}
> However {{getResources()}} doesn't just work against the 'latest' 
> classloader, but also considers the thread context classloader. In the case 
> of a Spring Boot app, Spring does provide such a classloader and 
> {{getResources}} is able to find the necessary resources {{CommandMarker}} 
> classes. (These classes are found within a nested jar. For ex. 
> {{jar:file:/Users/jdeppe/src/woddrive/WodDrive-GF-Server/target/WodDriveGFServer.jar!/lib/gemfire-core-1.0.0-incubating-SNAPSHOT.jar!/com/gemstone/gemfire/management/internal/cli/commands}}).
>  This is all fine, but subsequent code doesn't consider classes (or packages) 
> within nested jars, and in addition, when classes actually get resolved, the 
> thread context classloader (where those resources might have come from) is 
> not considered.

This message was sent by Atlassian JIRA

Reply via email to