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 20:01:50 GMT
It sounds like we're on the same page.

The current behavior requires two pieces from a user who wants to add
1) implement CommandMarker
2) Add a system property pointing to the package of your class, or provide
a file pointing to your class

The proposed behavior is to drop 2) and rely on 1) alone.

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

What I meant was, given our hammer of choice for GFSH is Spring Shell, all
command definitions should be of type CommandMarker.

Not sure how it loads the correct CommandMarker classes (for different
commands). But my gut feel is, have single way of doing something... KISS

On 5/25/17 12:22, Jared Stewart wrote:

> 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
> CommandMarker.
> This way we has standard simple way to specify commands.
> --Udo
> 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