Hi, Carsten Ziegeler schrieb: > 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.
+1 But leave the methods in the JcrResourceUtil forwarding to the new mehotds in the ResoureUtil class and deprecate them. Regards Felix > > 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 > >
