Re: Accumulo version at runtime?
Below is something I wrote for 1.4 that would grab the version using reflection. If the constant has moved in later versions, could gracefully handle class not found and field not found exceptions and look in other places. https://github.com/keith-turner/instamo/blob/master/src/main/java/instamo/MiniAccumuloCluster.java#L357 On Fri, Oct 24, 2014 at 1:38 AM, Dylan Hutchison dhutc...@stevens.edu wrote: How about a compromise: create *two classes *for the two versions, both implementing the same interface. Instantiate the class for the correct version either from (1) static configuration file or (2) runtime hack lookup to the version on the Monitor. (1) gives safety at the expense of the user having to specify another parameter. (2) looks like it will work at least in the near future going to 1.7, as well as for past versions. Thanks for the suggestions! I like the two classes approach better both as a developer and as a user; no need to juggle JARs. ~Dylan On Fri, Oct 24, 2014 at 12:41 AM, Sean Busbey bus...@cloudera.com wrote: On Thu, Oct 23, 2014 at 10:38 PM, Dylan Hutchison dhutc...@stevens.edu wrote: I'm working on a clean way to handle getting Accumulo monitor info for different versions of Accumulo, since I used methods to extract that information from Accumulo's internals which are version-dependent. As Sean wrote, these are not things one should do, but if it's a choice between getting the info or not... We're thinking of building separate JARs for each 1.x version. Why not just take the version of Accumulo you're going to talk to as configuration information that's given to you as a part of deploying your software? It'll make your life much simpler in the long run. -- Sean -- www.cs.stevens.edu/~dhutchis
Re: Accumulo version at runtime?
Dylan, I know your original post mentioned grabbing it through the client API but there's not currently a way to do that. As Sean mentioned, you can do it if you have access to the cluster. You can run the reflection Keith provided by adding the files in $ACCUMULO_HOME/lib/ to your classpath and running your code on the cluster. I definitely think exposing the server version should make it into 1.7. On Fri, Oct 24, 2014 at 6:00 PM, Dylan Hutchison dhutc...@stevens.edu wrote: Keith, I'm confused as to how you would run reflection Constants.class.getDeclaredField(VERSION).get(String.class) on the Accumulo server. Wouldn't we need to compile in a function returning that into the server for a custom Accumulo server build? Say we have a 1.6 Accumulo instance live. A client needs to know the version in order to load the appropriate class. How would you execute that code on the server if it is built from the standard Accumulo 1.6 binaries? On Fri, Oct 24, 2014 at 10:22 AM, Keith Turner ke...@deenlo.com wrote: Below is something I wrote for 1.4 that would grab the version using reflection. If the constant has moved in later versions, could gracefully handle class not found and field not found exceptions and look in other places. https://github.com/keith-turner/instamo/blob/master/src/main/java/instamo/MiniAccumuloCluster.java#L357 On Fri, Oct 24, 2014 at 1:38 AM, Dylan Hutchison dhutc...@stevens.edu wrote: How about a compromise: create *two classes *for the two versions, both implementing the same interface. Instantiate the class for the correct version either from (1) static configuration file or (2) runtime hack lookup to the version on the Monitor. (1) gives safety at the expense of the user having to specify another parameter. (2) looks like it will work at least in the near future going to 1.7, as well as for past versions. Thanks for the suggestions! I like the two classes approach better both as a developer and as a user; no need to juggle JARs. ~Dylan On Fri, Oct 24, 2014 at 12:41 AM, Sean Busbey bus...@cloudera.com wrote: On Thu, Oct 23, 2014 at 10:38 PM, Dylan Hutchison dhutc...@stevens.edu wrote: I'm working on a clean way to handle getting Accumulo monitor info for different versions of Accumulo, since I used methods to extract that information from Accumulo's internals which are version-dependent. As Sean wrote, these are not things one should do, but if it's a choice between getting the info or not... We're thinking of building separate JARs for each 1.x version. Why not just take the version of Accumulo you're going to talk to as configuration information that's given to you as a part of deploying your software? It'll make your life much simpler in the long run. -- Sean -- www.cs.stevens.edu/~dhutchis -- www.cs.stevens.edu/~dhutchis
Re: Accumulo version at runtime?
On Fri, Oct 24, 2014 at 6:00 PM, Dylan Hutchison dhutc...@stevens.edu wrote: Keith, I'm confused as to how you would run reflection Constants.class.getDeclaredField(VERSION).get(String.class) on the Accumulo server. Wouldn't we need to compile in a function returning that into the server for a custom Accumulo server build? Didn't realize you were looking for the info from a server. Thats certainly not going to work for that case. The approach is for getting client lib version. Say we have a 1.6 Accumulo instance live. A client needs to know the version in order to load the appropriate class. How would you execute that code on the server if it is built from the standard Accumulo 1.6 binaries? On Fri, Oct 24, 2014 at 10:22 AM, Keith Turner ke...@deenlo.com wrote: Below is something I wrote for 1.4 that would grab the version using reflection. If the constant has moved in later versions, could gracefully handle class not found and field not found exceptions and look in other places. https://github.com/keith-turner/instamo/blob/master/src/main/java/instamo/MiniAccumuloCluster.java#L357 On Fri, Oct 24, 2014 at 1:38 AM, Dylan Hutchison dhutc...@stevens.edu wrote: How about a compromise: create *two classes *for the two versions, both implementing the same interface. Instantiate the class for the correct version either from (1) static configuration file or (2) runtime hack lookup to the version on the Monitor. (1) gives safety at the expense of the user having to specify another parameter. (2) looks like it will work at least in the near future going to 1.7, as well as for past versions. Thanks for the suggestions! I like the two classes approach better both as a developer and as a user; no need to juggle JARs. ~Dylan On Fri, Oct 24, 2014 at 12:41 AM, Sean Busbey bus...@cloudera.com wrote: On Thu, Oct 23, 2014 at 10:38 PM, Dylan Hutchison dhutc...@stevens.edu wrote: I'm working on a clean way to handle getting Accumulo monitor info for different versions of Accumulo, since I used methods to extract that information from Accumulo's internals which are version-dependent. As Sean wrote, these are not things one should do, but if it's a choice between getting the info or not... We're thinking of building separate JARs for each 1.x version. Why not just take the version of Accumulo you're going to talk to as configuration information that's given to you as a part of deploying your software? It'll make your life much simpler in the long run. -- Sean -- www.cs.stevens.edu/~dhutchis -- www.cs.stevens.edu/~dhutchis
