I have talked with Christopher about the VFS class loader in general and I think he has a good approach. He can elaborate further if needed, but the approach is to move it out of the core project and allow users to configure it at runtime using the java.system.class.loader system property. There are organizations using the VFSClassloader successfully, maybe it just needs to be reimplemented.
On Wed, Oct 24, 2018 at 2:58 PM Sean Busbey <[email protected]> wrote: > sounds like a good DISCUSS thread for 2.0? > On Wed, Oct 24, 2018 at 1:43 PM Josh Elser <[email protected]> wrote: > > > > It seems like commons-vfs2 is just a pile of crap. > > > > It's been known to have bugs for years and we've seen zero progress from > > them on making them better. > > > > IMO, rip the whole damn thing out. > > > > On 10/24/18 12:42 PM, Matthew Peterson wrote: > > > Hello Accumulo, > > > > > > Summary: commons-vfs2 version 2.2 seems to have problems and it may be > > > worth rolling back to version 2.1 of commons-vfs2. > > > > > > My project upgraded a system from Accumulo 1.8.1 to 1.9.2. Immediately > > > after switching vfs contexts we saw problems. The tservers would > error in > > > iterators about missing classes that were clearly on the classpath. > The > > > problems were persistent until we replaced the commons-vfs2.jar with > > > version 2.1 (Accumulo 1.9.2 uses version 2.2). Until we rolled vfs > back, > > > we received errors particularly with Spring code trying to access > various > > > classes and files within the jars. It looks like in 2.2, commons-vfs > > > implemented a doDetach method which closed the zip files. We suspect > that > > > code is the problem but haven't tested that theory. > > > > > > I suspect that most users don't use this feature. > > > > > > Thanks! > > > Matt > > > > > > > -- > busbey >
