ctubbsii edited a comment on issue #1976: URL: https://github.com/apache/accumulo/issues/1976#issuecomment-809036899
> The obfuscation in the classloading code makes it difficult to debug what is going on. That complexity was one of the motivations for moving the classloading code out of Accumulo and supporting its features in a different way. The transition period is a bit rough, though, because we still have to support the existing behavior with the existing config. But, once we can drop these deprecated classes (presumably 3.0?), a lot of this code will make a lot more sense and these features will be much more maintainable. > I am not sure why the URLClassLoader is being used in this case as I would assume DefaultContextClassLoaderFactory would be the default. In order to preserve the existing behavior, the DefaultContextClassLoaderFactory currently delegates to the old AccumuloVFSClassLoader, which in turn, uses AccumuloClassLoader as the parent of any VFS classloaders it creates. This parent AccumuloClassLoader is little more than a wrapper around URLClassLoader designed to handle the URLs in the (now deprecated) `general.classpaths` property. So, URLClassLoader makes sense here. What doesn't make sense is why it's using the standard classloader, rather than the context-specific classloader. It's possible it's because the context for the table is being set after the table is created, and the property is being read from an outdated ZooCache from the table's initial creation, where the context is still null. Instead of setting the table property after the table is created, you could try setting it at creation time with `createtable -prop table.classpath.context=cx1 nofoo` -- 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. For queries about this service, please contact Infrastructure at: [email protected]
