Closed bbrownz closed 9 years ago
Looks okay to me. @rkanter, could you take a look?
It might make sense to go with the KiteConfigurationService in the other PR. It will allow Kite to be more flexible in the future. For example, if you want to use more than just Hive datasets, you may need other config files, which we wouldn't want the HCatAccessorService to load; with your own KiteConfigurationService, that wouldn't be a problem. And switching from HCatAccessorService to KiteConfigurationService later could be considered backwards incompatible because the oozie-site config property would change.
It sounds like we should take @rkanter's suggestion to add a KiteConfigurationService. Any thoughts @bbrownz?
Agreed, I've been meaning to get around to polishing up that branch so we can close this PR out in favor of the other one. Hopefully tomorrow :)
PR opened for the alternative implementation #405
https://issues.cloudera.org/browse/KITE-1035
Read the hive configuration from the HCatAccessorService in the KiteURIHandler to handle cases like view URIs without the metastore URI built in or more complex situations where kerberos needs to be configured for Hive.
Since this makes use of the HCatAccessorService configuration it's limited to hive configuration. A potential alternative can be seen in the commit here where a configuration service is added specifically for Kite. The configuration is read from a list of potential configurations. This has the additional downside of requiring to consumer to configure the location of these config files as well as specify that Oozie should load the service.