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