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 <[email protected]> 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 >> >>
