Juan José Ramos Cassella commented on GEODE-800:

Hey [~francesco.foresti],

The issue can be resolved by using the latest version of the 
{{fast-classpath-scanner}} library as the dependency, namely {{2.18.1}}, 
instead of the one transitively included by Geode, namely {{2.0.11}}.

The only remaining question is : why Geode doesn't depend on the correct 
version by default?.

Geode proactively updates its dependencies regularly (there's actually a [pull 
request|https://github.com/apache/geode/pull/1400] opened to update some 
dependencies at the moment) but, as you can see from the [Maven Central 
 and the relevant [Source Code 
Releases|https://github.com/lukehutch/fast-classpath-scanner/releases], this 
particular library has itself changed regularly these last couple of weeks.
Hope this helps.

> 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
>         Attachments: geode-800-testcase.zip
> 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