geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jared Stewart <jstew...@pivotal.io>
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
META-INF.services file?

On May 25, 2017 12:18 PM, "Udo Kohlmeyer" <ukohlmeyer@pivotal.io> wrote:

imo, I think that GFSH is Spring Shell, it should really only be commands
that are registered inside of META-INF.services .. 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 "org.apache.geode.management.i
> 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
> META-INF.services (e.g. "geode-core/src/test/resources
> /META-INF/services/org.springframework.shell.core.CommandMarker”)
>
> 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?
>

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