Hi, Ian Boston schrieb: > > On 6 May 2009, at 20:23, Felix Meschberger wrote: > >> I have to admit, that I have my issues with this patch, too. First it >> introduces new API and second it exposes a Jackrabbit internal feature >> (SynchronousEventListener) which is AFAICT not intended for general use. >> >> May I ask you, what your use case for the SynchronousEventListener is ? > > > We need to get access to items before they are saved to > a) set additional node properties > b) apply some rules on node properties.
Hmm, not knowing the exact details, I would assume that in your synchronous listener you have a JCR session, which you use to update the content. So it would be something like: User Session US modifies content Synchronous Listener gets notified Synchronous Listener Session SLS modifies content again Correct. Now, I don't completely understand what the advantage of using a synchronous listener really is - or is it for the "Transaction Context" you are referring to below ? > >> >> >> So I would also prefer a solution, which the standard OSGi Event Admin >> service: Using service registration properties EventHandler services may >> limit the events they receive. >> >> To support Jackrabbit SynchronousEventListeners, the OSGi EventAdmin >> bridge (bridging JCR events to OSGi events) may use synchronous event >> delivery (EventAdmin.sendEvent). For normal EventListeners, the regular >> asynchronous event delivery (EventAdmin.postEvent) is used. >> >> WDYT ? > > yes, that might work for us, > I assume by synchronous they are on the same thread No, you cannot assume that you are running in the same thread, the save assumption as per the OSGi EventAdmin spüec is, that it may be the same thread must is not required to be. But you may assume that the listener is called synchronously. > and share the same Transaction context ? I am not sure, what exactly you mean here. Is the listeners session associated with the "Transaction context" while updating more properties ? Now, the question is of course, how the listener session gets to the "Transaction context" to associate with. If it is a ThreadLocal property, you may be lost with EventAdmin. Maybe Jackrabbit SynchronouseEventListener is so special, that we expose special API from the jackrabbit-server bundle to support such synchronous listeners. Regards Felix
