ctubbsii commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1604955414
@alerman Thanks for the clarification. I misunderstood @ivakegg 's
explanation, and thought the clone table's config was being copied. I now
understand that the problem was in the cloned table itself, not a table created
using it as a template.
@ddanielr One quirk about the shell's `config` command is that you can't see
overrides at all, unless they differ from the parent, because there is no
public API to see only the properties set on a table, but ignoring stuff coming
from underneath. So, the shell can only see these overrides after the system
property has changed.
But yes, we absolutely could provide a flag, and a new public API to view
the overrides, or view only the specific scoped properties, without showing the
effective properties from the entire hierarchy, and we could also add a new
`-cc`-like flag that only uses those properties as a template, instead of the
effective properties.
***
However, there's a much simpler solution that is immediately available to
the users impacted by the current behavior: just don't use the per-table
property to specify the context the way you're doing it. Instead, use a custom
property name that holds the URLs (or other context) that isn't a per-table
property that gets copied, and use the table parameter as a context group
reference that doesn't change. This merely takes a small bit of imagination to
implement.
For example:
```java
public class MyCustomClassLoaderContextFactory implements
ContextClassLoaderFactory {
private ContextClassLoaderEnvironment env;
@Override
public void init(ContextClassLoaderEnvironment env) {
this.env = env;
}
@Override
public ClassLoader getClassLoader(String contextGroup) {
// interpret context parameter as a "context group", but read current
URLs from a different location
String urls =
env.getConfiguration().get("general.custom.myclassloader.group." +
contextGroup);
// ... create new URLClassLoader from urls and return that
}
}
```
So now, instead of changing the per-table property at the system level, you
change this other property that is the actual context for that contextGroup by
editing `general.custom.myclassloader.group.somegroupname` and
`table.class.loader.context` just stays fixed at `somegroupname` and is set
only on the table, not at the system (but even if it's set at the system, it's
not a problem, if it's never changed).
This is actually way more powerful than what you are currently doing,
because you can still get different classloaders for different groups of
tables, whereas the way you're currently using the table property at the system
config, your factory would necessarily give the same classloader to every table
in the system.
In my example, the context you're changing is a set of URLs, but it could be
something else, depending on your factory implementation. It could even be
another redirect to a named URL set, if you want to stage different named URL
sets in your config, and then just swap them out by name in your factory.
This is the power of the pluggable factory interface that we made, and one
of the reasons we designed it this way... you are no longer bound to the
limitations of our previous ways of doing per-table classloader contexts... you
can use these contexts as indirect jumps to your mutable contexts. Your
contexts on your tables can represent anything you wish.
***
So, yes, we can add the API updates and flags to the shell command... but
even if we didn't, you don't need to let this limitation affect you. You just
need to use the new context and factory SPI a bit more effectively.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
