[
https://issues.apache.org/jira/browse/GEODE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16360530#comment-16360530
]
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}}.
{quote}
The only remaining question is : why Geode doesn't depend on the correct
version by default?.
{quote}
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
Repository|https://mvnrepository.com/artifact/io.github.lukehutch/fast-classpath-scanner]
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.
Cheers.
> 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
(v7.6.3#76005)
