Bernd Eckenfels wrote: > Hello, > > While fixing some locking consistence issues around find/closeFileSystem > I noticed that the AbstractVfsContainer#components ArrayList has quite > some problems (linear search, duplicate entries). > > I started to fix this up but then I noticed that it is actually not > needed: AbstractFileProvider does maintain a second cache of all its > components (=file systems). That one has better properties (but needs > synchronisation). > > I can remove addComponent()/removeComponent() from > AbstractFileProvider, however it looks like it is also possible to > directly remove it from the inheritance hierache as wll (which would > safe us a field). > > What do you think? > > (VirtualFileProvider is special, but it think the best thing is to make > it extend AbstractFileProvider as well, would solve other issues as > well) > > (the following is an edited diff, it does not contain all "before -" > lines for the javadoc changes to make it better readable. I let you > review the full patch once we agreed that it is a good think). > > The following patch also removed the AbstractVfsContainer from the > hierachy, we can keep it if you think it is safer. (also it might be > confusing to have the components not maintained with it).
You cannot, because of binary compatibility. If you intend to remove AbstractVfsContainer altogether, then deprecate it, turn the two methods into an empty implementation and remove the member. That will allow us to remove the class in 3.x. Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
