Another minor issue are the helper methods of the JcrResourceUtil class (the getResourceSuperType, resourceTypeToPath methods). I think we can make them completly JCR free and move them to the ResourceUtil class in the API.
Carsten Carsten Ziegeler wrote: > Hi, > > I'm currently working on improving the script resolution in terms of > performance. > While looking at how it works today, I've discovered two problematic points: > > 1) Currently the scripts are searched by using the session of the > current request. Now, I think using the user session to search the > script is wrong. The content, the user requests, is already retrieved > with the user session and its the content (or the acl's on the content) > who define if the user is allowed to access something. > The script should always be executable (and I'm speaking of execution > not reading, writing etc.) for any user. This also matches the current > handling for scripts which are not stored in the repository like the > servlets or scripts contained in bundle resources. > > Therefore I suggest to change the script resolution to use the admin > session. > > Btw, this would also make caching the script resolution easier as the > current approach requires the caching of the script resolution to be a > per user cache. With the changes from above the cache can be global. > > 2) Resource events > > We need to implement https://issues.apache.org/jira/browse/SLING-944 and > some extension of this to properly update the cache if scripts are > changed, added removed. As scripts can be coming from any data source > (jcr, file system, bundle, database etc.) we need a generic mechanism here. > For now I think we could start with OSGi events for > - Resource added, removed, changed > - Resource Provider added, removed > > WDYT? > > Carsten -- Carsten Ziegeler [email protected]
