accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: ClientConfiguration doesn't check classpath
Date Thu, 30 Jun 2016 00:21:19 GMT
Being able to pull off of the classpath would certainly be nice when you
want to interact with multiple instances from the same host (thus requiring
different client confs).

Christopher's #1 point would also be a similar solution to the same
problem. I'm not sure if one or the other would be better/worse.
On Jun 29, 2016 3:24 PM, "Christopher" <ctubbsii@apache.org> wrote:

> 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
> like:
>
> 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
> (/etc/application/config)
> (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 <madrob@cloudera.com> 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
> >
>

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