Hello all,
I'm sorry I've been very busy but as promised I would like to fix HSEARCH-189
(and others) very soon;
I would like to propose a API extension (backwards compatible) that would simplify the patch a lot:
keeping it as is it is very tricky to fix the visibility issues in FSSlaveDirectoryProvider
and FSMasterDirectoryProvider without introducing a performance penalty.
I have these options to close the issue:
1) add a "volatile" to more than six fields per class (ugly and not good for performance)
2) use some Locks/synch (more readable, still performance hits)
3) move the "initialize" arguments to a constructor.
As Emmanuel knows I would really love the third option, but he's worried about
the fact we can't force a constructor in an interface*1, so my proposal is:
if we find there exists a constructor having the same arguments as the initialize method,
we use that, otherwise we use a no-arg constructor and then call the initialize.
Reflection is used anyway to instantiate these components,
the code in DirectoryProviderFactory doesn't get much more complicated
and much more cleanup is made possible in all DPs because of this
(as the equals/hashcode comments already ask for).
I actually think this same pattern is needed for other components,
such as all ReaderProvider, so I hope you'll want to give it a try
and let me apply it on other components too if you like the resulting code.
Sanne