Was thinking about this a bit more. One of the problems with classpath is that makes it a bit hard to pull different configs within the same JVM (multiple client connections). It can also come from unexpected jars, resulting in surprising behavior. And, it depends on the classloader used at runtime. It can be quite unpredictable. An option to pull from the classpath with a flag would be nice, though, for executing in something like a servlet container.
On Wed, Jun 29, 2016 at 8:21 PM Josh Elser <josh.el...@gmail.com> wrote: > 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" <ctubb...@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 <mad...@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 > > > > > >
