You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For get jars command add in #907 the command expects the target directory to exist but does not care if the directory is non-empty. I found myself wondering if the behavior should change or if the docs should be improved to clearly state the behavior for a non-empty dir while looking at the PR. I was not sure. Below are some thoughts I had.
Should the get jars command create the dir?
If the directory is not empty should the get jars command fail? Their are two use cases to consider.
A user intentionally adds jars to a dir before calling get jars and does not expect it to empty.
A user unintentionally reuses a dir and expects the dir to be empty when its not and ends ups extra/unexpected jars in the dir.
The text was updated successfully, but these errors were encountered:
Could classes be loaded from HDFS directly using Accumulo's VFS classloader?
Yes. One possible way to do this would be to run fluo config -a <app> and grep for the property fluo.observer.jars.url. Its also possible to obtain this property via the Java API using FluoAdmin.getApplicationConfig(). Then the VFS classloader could be configured to use this.
Fluo is not currently using the VFS classloader for itself though. Currently its not doing anything with classloaders and relying on the launch scripts to setup its classpath.
For get jars command add in #907 the command expects the target directory to exist but does not care if the directory is non-empty. I found myself wondering if the behavior should change or if the docs should be improved to clearly state the behavior for a non-empty dir while looking at the PR. I was not sure. Below are some thoughts I had.
The text was updated successfully, but these errors were encountered: