I'm sorry I've been very busy but as promised I would like to fix
(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
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
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
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
we use that, otherwise we use a no-arg constructor and then call the
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.
Pardon me if it has been answered before but I could not find
via different searches on Hibernate or Google.
createSQLQuery("select * from A,B where <condition>").iterate() /scroll()
to get earch row and do processing.
the doc says the above returns Object , which is great
except that but there is no public API to access the
ResultSetMetaData even though the doc says it uses it to derive column info.
I wonder if this object could be exposed.
Thanks in advance.