Hi, I just got aware that we might have potential problems with the way script resolving is done atm.
Currently, the script resolver opens a long lived script session. By default this is an admin session, but can be configured to user a different user. The script resolver is used concurrently and therefore the underlying session is accessed concurrently which neither by the Sling API nor by the JCR API is guaranteed to work. In addition, looking at Oak (the new jackrabbit implementation) it seems that long lived sessions should refresh themselves before reading from the repository. And I guess this is nothing which will work concurrently. On the other hand, I don't want to add syncing on the resource resolver. But the problem is slightly larger: other parts in Sling need to have access to the script resolver as well. To avoid configuring the same script user over and over again in different bundles, we came up with the solution that the script resolver buts the used resource resolver into a request attribute. This is picked up by e.g. the jsp scripting and used there to read scripts (like included jsps etc.) So even if we would sync the script resolver, access in the script implementations like jsps might happen concurrent (either concurrent to itself or concurrent to the script resolver). And finally, once a script is resolved by the script resolver, the underlying resource keeps a reference to the used resource resolver (which in turn references the script session.). The servlet might end up in the servlet cache, so we can't close the correspoding script resolver otherwise this would render the script resources invalid. Obviously, one problem arises from the fact that we wanted to configure a script user only in one place, otherwise we could solve the problems in the script resolver and the (jsp) scripting independently. So what about tackling the problem from the other side: we define a role in Sling like SCRIPT_ADMIN. When a component in Sling requires a script admin, it passes this information into the ResourceResolverFactory.loginAdministrative and somehow gets the correct resource resolver (and underlying session). The configuration how to get such a script admin is then a configuration of the resource resolver factory or some other module. This would allow the script resolution to use such a user as well as the jsp scripting without passing the resource resolver from one to another. In addition, this could also be used in the servlet resource provider: if the user is not a script admin the resource is not accessible. The script resolution creates the required resource resolvers on demand and does not hold a long lived reference anymore. This solves the potential concurrency problems. As the final step, we have to make sure that the (cached) servlet/script does not hold a reference to a script resource resolver forever, it can get them on demand. There shouldn't only be a few uses of this. There might be some wringles to straighten, but WDYT about this in general? Regards Carsten -- Carsten Ziegeler [email protected]
