Hi Amin, thanks for the update, see some thoughts: 2010/3/16 Amin Mohammed-Coleman <ami...@gmail.com>: > Hi folks, > > I've removed the enum singleton and created a class(BackendExceptionHandler) > which has 2 methods: > > > public Thread.UncaughtExceptionHandler > getUncaughtExceptionHandler(SearchConfiguration configuration); > > 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. [1] The solution is, as we do with all components, to start them during SearchFactory initialization and then expose a getter to initialized service. [1] http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-314 Cheers and thanks for the complex work, Sanne > > > Thanks for your patience with this one. > > Cheers > Amin > > > > > 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. >> >> Cheers >> >> Amin >> >> Sent from my iPhone >> >> On 9 Mar 2010, at 12:47, Sanne Grinovero <sanne.grinov...@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 <emman...@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. >>>> >>>> > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
