I've attached a new patch file and comment to
someone could take a look.
On 1 May 2013 21:48, Christopher <[EMAIL PROTECTED]> wrote:
> Responses inline below:
> On Wed, May 1, 2013 at 4:30 AM, Rob Tallis <[EMAIL PROTECTED]> wrote:
> > Hi
> > I'm new to accumulo, new to open source projects. I want to pick up
> > Accumulo-1070 (Improve Audit Messages) from where Phil Young left off.
> > a bunch of questions about how I go about this.
> > - Why is there an svn and a github repository? Which should I be
> SVN is our primary. GIT is a mirror and may lag commits to SVN. You
> can use whichever is more convenient for you.
> > - What's the workflow for me submitting a change? Do I upload a patch
> > file to the ticket? We then go back and forward on the ticket until
> > happy with the patch?
> Yes, essentially, you create a patch and attach it to a ticket to
> > On the specific task, here's what I'd like to do:
> > - In AuditedSecurityOperation.java - Phil and Keith found that
> > a getInstance() implementation here, the bulk of that class is never
> > and the audit messages already in there haven't seen the light of
> day. Once
> > fixed, I want to rewrite the messages so they are less "prose" and
> > machine-readable.
> > - Get rid of the custom AuditLevel.java and use a separate Audit
> > - Stick the Logger and Appender config in a new log4j xml config file.
> > Sites can configure easily where they want the messages to go. I want
> > stick all the audit messages in a separate file (or files).
> > - (maybe) implement config to enable/disable auditing based on user.
> Sounds reasonable to me. Your patch may get reviewed by one or more
> committers before acceptance, though.
> > In the ticket comments Keith said:
> > - "Will be logging binary data,this will be lossy. For example it will
> > log the columns a user fetches. Could consider encoding base64
> > characters, but I am not sure about this."
> > I don't understand this, column names can be binary? Where does that
> Yes, essentially fields in Accumulo (except the timestamp and
> visibility) are arbitrary bytes. They may or may not represent
> human-readable strings. We don't enforce a constraint that they be
> human-readable strings.
> > Also, do you have an indication when 1.5 will get released? I need to do
> > local patch for the "current" version to keep my org happy, if 1.5 is
> > imminent I won't need to bother with 1.4 (this is just for my use).
> I'm planning to roll out a release candidate Friday for a test vote.
> > Thanks,
> > Rob Tallis
> Christopher L Tubbs II