accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: Accumulo version at runtime?
Date Fri, 24 Oct 2014 23:30:56 GMT
On Fri, Oct 24, 2014 at 6:00 PM, Dylan Hutchison <dhutchis@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 <keith@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 <dhutchis@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 <busbey@cloudera.com>
>>> wrote:
>>>
>>>>
>>>> On Thu, Oct 23, 2014 at 10:38 PM, Dylan Hutchison <dhutchis@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
>

Mime
View raw message