thanks for the update, see some thoughts:
2010/3/16 Amin Mohammed-Coleman <aminmc(a)gmail.com>:
I've removed the enum singleton and created a class(BackendExceptionHandler) which
has 2 methods:
public Thread.UncaughtExceptionHandler getUncaughtExceptionHandler(SearchConfiguration
public boolean logException(SearchConfiguration configuration)
Care to explain how I should use them? Are we not going to have a
common interface? In that case does it make sense to have a method
named "logException", which would imply a logging implementation?
The issue that I'm looking at is getting the search configuration to the methods. In
order to get the SearchConfiguration to the methods defined in BackendExceptionHandler, I
have to thread SearchFactoryImplementor.
Using this approach I will have to define a method to get the search configuration from
the SearchFactoryImplementor. I'm guess this isn't the best approach as this
requires a significant change. I don't know what peoples thoughts are on this.
I'm looking to set the BackendExceptionHandler up when the SearchFactory is created
and then use it. Is there any currently approach that does something similar?
Ah there's a subtle problem with that, which is that we can't hold a
reference in Search to a Configuration at runtime: use it at
SearchFactory creation, extract all what you need, but then you have
to clear references or we're going to have a memory leak. 
The solution is, as we do with all components, to start them during
SearchFactory initialization and then expose a getter to initialized
Cheers and thanks for the complex work,
Thanks for your patience with this one.
On 9 Mar 2010, at 13:00, Amin Mohammed-Coleman wrote:
> Hi Sanne
> You are right and Im not happy with the enum class. I wanted to have a single
configuration that was available on the creation of the search factory and re use when
required. I'll take a look at changing that with a better solution.
> Sent from my iPhone
> On 9 Mar 2010, at 12:47, Sanne Grinovero <sanne.grinovero(a)gmail.com> wrote:
>> yes that is it;
>> There has been some talking about other strategies as well on previous
>> mails, like jms, but that lead to nowhere so yes I'm suggesting now to
>> forget about other default implementations at the moment and proceed
>> as you just said.
>> 2010/3/9 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>> I thought the goal was to have something pluggable with two default impls
(exception and log). If that's what you are describing I am ok, if not, then I
don't understand ;)
>>> On 9 mars 2010, at 12:08, Sanne Grinovero wrote:
>>>> Emmanuel are you ok with this if we either log or rethrow the
>>>> exception back to application code? jms et al looks complex and I
>>>> don't see the benefit.