Hi- On Wed, Mar 24, 2010 at 4:17 AM, Carsten Ziegeler <[email protected]>wrote:
> > Author: justin > > Date: Sat Mar 20 02:22:25 2010 > > New Revision: 925531 > > > > URL: http://svn.apache.org/viewvc?rev=925531&view=rev > > Log: > > SLING-1447 - adding ability to configure multiple workspaces for event > firing > > Hi, > > at first I thought that this is a good idea, but rethinking it, I'm not > sure anymore. > The problem I see is that if two workspaces contain the same content (or > partially the same content), then resource events might be fired because > something changes in workspace x (which is not the default workspace) - > but event handlers for these events assume that the changes happened in > the default workspace. > Resource events have only the path property by default and event handler > do not expect an additional workspace prop. > > I guess first and foremost, the thing I would say is that if you configure Sling such that it fires events for non-default workspaces, you understand the consequences of doing so... and that while it is true that the current set of event handlers do not expect an additional property, this can be changed where necessary. I should also say that I had the (faulty) assumption that I would be able to discuss this multi-workspace stuff face to face with some other Sling devs at OSGi DevCon [Karl - I enjoyed drinking with you, but this didn't really seem to be an area of interest :)]. > So I think have to change this, adding the workspace to the path > property (if it is not the default workspace) would do the trick. > Wouldn't this break existing event handlers? If an event handler expects the path to be a resource/jcr path, and it gets test:/foo/bar (workspace = test, path = /foo/bar), the event handler will fail. What might be interesting (haven't yet finished my first cup of coffee today) is to add a new property to the event which contains a URI, e.g. resource://test/foo/bar, deprecate the path property, and then migrate event listeners to rely on this new uri property. Justin > > WDYT? > Carsten > -- > Carsten Ziegeler > [email protected] >
