Felix- I know this probably isn't a great answer, but I think we just have to start somewhere. If the answer is that this should happen in a branch, I'm fine with that, but I personally don't think it's necessary - any change along these lines should be able to be fully backwards compatible.
Two other things come to mind are content loading and jcr resource events. Justin On 3/17/10 10:06 AM, Felix Meschberger wrote: > Hi, > > On 17.03.2010 02:45, Justin Edelson wrote: >> Currently, although it's possible to log into different workspaces via >> AuthenticationInfo (even if httpauth and formauth don't support this); >> script resolution only happens against the default workspace. I don't >> see any reason for this restriction - it seems to me you should resolve >> scripts from the same workspace as the one resource was resolved from. WDYT? > > IIRC there have been some discussions around this (if only in my head > with myself ;-) ) issue. It was merely about the question "will sling > work if the main access is to another workspace ?" > > At that time, it (probably mostly) did, because the ScriptResolver used > the ResourceResolver from the request, which was properly set up for the > same workspace as the request. > > Nowadays, I fear it is not enough to just make the ScriptResolver > multi-workspace aware -- the repository-based class loaders must also be > made aware of this. Likewise the JSPScriptEngineFactory should probably > also not compile scripts from a secondary workspace into the primary > workspace /var/classes .... > > We might want to find a generic mechanism to be able to handle requests > completely out of a secondary workspace - is this possible ? How ? > > Regards > Felix > >> >> I think I've resolved this locally (still testing), but wanted to get >> some feedback before committing it. >> >> Thanks, >> Justin >>
