geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jared Stewart <>
Subject Re: Proposal: Remove the "user-command-packages" system property
Date Thu, 25 May 2017 19:22:19 GMT
Can you clarify - I'm proposing we use *implements CommandMarker* alone as
the way to specify commands. What do we gain be *also* requiring a file?

On May 25, 2017 12:18 PM, "Udo Kohlmeyer" <> wrote:

imo, I think that GFSH is Spring Shell, it should really only be commands
that are registered inside of .. aka implements

This way we has standard simple way to specify commands.


On 5/25/17 11:52, Jared Stewart wrote:

> I would like to propose that we eliminate the “user-command-packages”
> system property, in favor of scanning the entire classpath to find commands.
> To give more detail, Geode currently supports three ways to load GFSH
> commands:
> Scan the classpath for commands in "
> nternal.cli.commands”
> Scan the classpath for commands in a package specified by a user via the
> “user-command-packages” system property.
> Scan the classpath for commands registered in files inside
> (e.g. "geode-core/src/test/resources
> /META-INF/services/”)
> We have some bespoke code responsible for scanning the classpath
> (ClasspathScanLoadHelper) that I am in the process of replacing with
> FastClasspathScanner (GEODE-2989).  Since FastClasspathScanner will no
> longer need to eagerly load all of the classes in the target package, I
> don’t see any reason why a user should need to specify a
> “user-command-package” property or a “META-INF/services” file.  Instead, we
> should just scan the whole classpath and register any commands that we find.
> Thoughts?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message