Thanks - I had completely glossed over the "config -ns" option. So not an edge case - rather just pure mea culpa. I'll test it tomorrow but looks like it should do exactly what I need.
Chris On Tue, Dec 16, 2014 at 12:59 AM, Christopher <ctubb...@apache.org> wrote: > > I'd imagine you can set the context classpath for the entire namespace > with: > > # this in the accumulo-site.xml > general.vfs.context.classpath.mycontext=jar1,jar2,jar3,etc. > and > # this in the namespace config > table.classpath.context=mycontext > > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > On Mon, Dec 15, 2014 at 11:46 PM, Josh Elser <josh.el...@gmail.com> wrote: > > > > In essence, you're asking to apply some context classloader to a > namespace > > and have it propagate down to each table in that namespace as opposed to > > setting it on each table? By doing so, you wouldn't have to ensure that > > each table for your logical "application" is configured with the same > > context classloader. > > > > If that's the case, +1 for the change -- nearly all of our properties > > already "delegate" in that fashion: per-table inherits from namespace > which > > inherits from system. I'm a little sad if it doesn't actually already do > it > > (because that means classloader configuration is an edge case > internally), > > but happy that you'd like to work on it :) > > > > > > Chris Bennight wrote: > > > >> (Note - my assumption here is that I can't currently assign an isolated > >> classpath as "default" for a particular namespace; if I missed > something > >> apologies) > >> > >> So I get the ability to assign an application specific classpath on a > per > >> table basis. In my case I create (and sometimes remove) tables via the > >> API > >> (as opposed to the shell) - which scope normally mediated by a > namespace. > >> > >> I can attach an application classpath at creation to each table, but > this > >> requires sharing information (name of application classpath somehow > >> configured/set for application), or convention (always call it "xyz") > >> between the accumulo config and client application. > >> > >> I think a cleaner solution in this part would be to let the classpath be > >> tied through accumulo configuration to the namespace (this would also > make > >> classpath isolation easier for other programs - they don't have to add > in > >> hooks in the case of programatically creating tables). > >> > >> So my questions: > >> -- Is this something that is already in the works? (I swear, I looked > in > >> JIRA) > >> -- Is it a terrible idea (why?) > >> -- If it's not already done, and not a bad idea, should I create a > ticket, > >> propose a design, and start coding after vetting? > >> > >> Thanks, > >> Chris > >> > >> >
