accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: ClientConfiguration doesn't check classpath
Date Wed, 29 Jun 2016 22:24:02 GMT
To get rid of the warning, don't use ClientConfiguration.loadDefault().
Unit tests should be self-contained, and not use the user's environment.
Instead, use "new ClientConfiguration()". If you're still getting that
warning, we need to fix it. That constructor shouldn't be reading any
external config.

To the discussion:

I think the expected behavior for a typical application would be something

1. Check for command-line parameter (like --config) or ENV
2. Check in well-known user-specific location ($HOME/.dotfile, similar)
3. Check in well-known application-specific location
(sometimes, #3 is done first, and #2 or #1 can supplement/override)

Java gives us the additional option of using the CLASSPATH for config
files. Personally, I'm not a big fan of that, because classpaths are messy
things, and it can result in unpredictable behavior. I'd prefer to stick as
closely to the model above. However, I can see some advantages to using the
classpath, particularly in containerized execution environments where the
config file can't be provided via the filesystem. Regardless of what we do,
it should be intuitive and well-defined, though.

On Wed, Jun 29, 2016 at 5:42 PM Mike Drob <> wrote:

> Devs,
> Is there a reason that ClientConfiguration looks in the user's home
> directory, and for environment variables ACCUMULO_CONF_DIR and
> ACCUMULO_HOME to find a configuration but can't be controlled via system
> properties or the classpath?
> I'm working on some unit tests and keep seeing 'WARN
> org.apache.accumulo.core.client.ClientConfiguration  - Found no client.conf
> in default paths. Using default client configuration values.'
> What's the preferred solution here?
> Thanks,
> Mike

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