Namespaces & Application Classpath interplay

[Chris Bennight <ch...@slowcar.net>]

(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

Re: Namespaces & Application Classpath interplay

[Chris Bennight <ch...@slowcar.net>]

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 <ct...@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 <jo...@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
> >>
> >>
>

Re: Namespaces & Application Classpath interplay

[Christopher <ct...@apache.org>]

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 <jo...@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
>>
>>

Re: Namespaces & Application Classpath interplay

[Josh Elser <jo...@gmail.com>]

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
>