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