accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: ClientConfiguration doesn't check classpath
Date Thu, 30 Jun 2016 15:12:38 GMT
On Wed, Jun 29, 2016 at 5: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.
>
> I'm calling new ZookeeperInstance(instanceName, zooKeepers) which calls
ClientConfiguration.loadDefault() for me. Maybe need to deprecate all of
the ZKI constructors that don't take a configuration object due to this
warning? That would be really cumbersome from a usability perspective
though.


> 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