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
>
