Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> AccumuloToken


Copy link to this message
-
AccumuloToken
I'm having some problems with AccumuloToken.  Christopher has already
brought it up in IRC, and I agree.  I'm putting it out on the list for a
more inclusive discussion.

I don't like exposing thrift as the serialization mechanism.  In
particular, this just hurts my eyes:

public interface AccumuloToken
<T extends TBase<?,?>, F extends TFieldIdEnum> extends TBase<T, F>,
Destroyable {
...
}

Is there some reason this is not just:

public interface AccumuloToken extends Writable, Destroyable {
...
}

I've switched this in my local development environment and it seems to work
just fine.

I don't like the class name.  Is there some reason why Accumulo isn't just
assumed and we call this Token or Credential, or even SecurityToken?

I don't like the rest of the code being littered with deprecation warnings.
 If we're not willing to switch the code over to The New Way, why should we
expect our users?

Are there not some security implications of dynamic class loading for
authorization when the class name is specified *by the remote caller*?

And I know a punched the Proxy in at the last second, but is there
something we should do with security to avoid changes to this new API?

-Eric
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB