After some reading about Accumulo classpaths since v1.5 it looks like the cleanest way to configure the geowave-accumulo.jar would be to configure a geowave application specific classpath context and then label our tables appropriately to use this context.
I'm not as sure about the best way to incorporate the needed steps into either a procedure or directly into the code base but the example below shows the minimum possible to make things work.
Given the documentation settings override precedence at https://github.com/apache/accumulo/blob/1.5/core/src/main/resources/org/apache/accumulo/core/conf/config.html#L24-28 it looks like Zookeeper settings trump those set in the accumulo-site.xml file. So the manual configuration command from the accumulo shell would be config -s general.vfs.context.classpath.geowave=hdfs://HDFS_NAME_NODE:8020/accumulo/classpath/geowave-accumulo.jar which would succeed once the geowave-accumulo.rpm has been installed as it copies the jar file into that location in HDFS and sets ownership/permissions.
The second step of labeling any geowave tables could be minimally accomplished with something like the following one line change.
diff --git a/geowave-accumulo/src/main/java/mil/nga/giat/geowave/accumulo/BasicAccumuloOperations.java b/geowave-accumulo/src/main/java/mil/nga/giat/geowave/accumulo/BasicAccumuloOperations.java
index 3f13177..a988c4c 100644
--- a/geowave-accumulo/src/main/java/mil/nga/giat/geowave/accumulo/BasicAccumuloOperations.java
+++ b/geowave-accumulo/src/main/java/mil/nga/giat/geowave/accumulo/BasicAccumuloOperations.java
@@ -221,7 +221,6 @@ public class BasicAccumuloOperations implements
try {
connector.tableOperations().create(
qName);
-
connector.tableOperations().setProperty(qName, "table.classpath.context", "geowave");
}
catch (AccumuloException | AccumuloSecurityException | TableExistsException e) {
LOGGER.warn(
I think the configuration of the app specific context classpth could probably be automated as well but we'd probably need to do some discovery and sanity checking of hostname/path/artifact first. At the point any of these settings do not line up correctly an error is thrown within Accumulo but as it is app context and table specific it does not seem to affect the operation of the overall container.
After some reading about Accumulo classpaths since v1.5 it looks like the cleanest way to configure the geowave-accumulo.jar would be to configure a geowave application specific classpath context and then label our tables appropriately to use this context.
I'm not as sure about the best way to incorporate the needed steps into either a procedure or directly into the code base but the example below shows the minimum possible to make things work.
Given the documentation settings override precedence at https://github.com/apache/accumulo/blob/1.5/core/src/main/resources/org/apache/accumulo/core/conf/config.html#L24-28 it looks like Zookeeper settings trump those set in the accumulo-site.xml file. So the manual configuration command from the accumulo shell would be config -s general.vfs.context.classpath.geowave=hdfs://HDFS_NAME_NODE:8020/accumulo/classpath/geowave-accumulo.jar which would succeed once the geowave-accumulo.rpm has been installed as it copies the jar file into that location in HDFS and sets ownership/permissions.
The second step of labeling any geowave tables could be minimally accomplished with something like the following one line change.
diff --git a/geowave-accumulo/src/main/java/mil/nga/giat/geowave/accumulo/BasicAccumuloOperations.java b/geowave-accumulo/src/main/java/mil/nga/giat/geowave/accumulo/BasicAccumuloOperations.java
index 3f13177..a988c4c 100644
--- a/geowave-accumulo/src/main/java/mil/nga/giat/geowave/accumulo/BasicAccumuloOperations.java
+++ b/geowave-accumulo/src/main/java/mil/nga/giat/geowave/accumulo/BasicAccumuloOperations.java
@@ -221,7 +221,6 @@ public class BasicAccumuloOperations implements
try {
connector.tableOperations().create(
qName);
I think the configuration of the app specific context classpth could probably be automated as well but we'd probably need to do some discovery and sanity checking of hostname/path/artifact first. At the point any of these settings do not line up correctly an error is thrown within Accumulo but as it is app context and table specific it does not seem to affect the operation of the overall container.