Hi > On 28.12.2009 17:08, Carsten Ziegeler wrote: > > When we're doing changes in this area, we might also look > at the same > > time at one of the things which is on our todo list for a > long time :) > > > > The basic question: how to get a resource resolver? > > > (http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/ 200811.mbox/%3c491727d7.4070...@gmail.com%3e)
>Yes, we should definitely pick this up again .... > >>From a Sling perspective I guess after authentication happend, a >> resource resolver for the current user is available (somehow) - we >> shouldn't use the session approach like we have now. Therefore looking >> at how to create a resource resolver from some factory might be help here. >Agreed, regardless of the above the standalone authenticator will >provide a ResourceResolver and not a Session as a request attribute. At the risk of coming a little bit late into this discussion I nevertheless try to give my point of view. I really think while changing the authentication process we should consider of implementing what Felix proposes on [1] for an ResourceResolverFactory. I would like to have the authentication process even more decoupled from JCR and the ResourceResolver. The authentication process should authenticate the user and that's it. To force this process also to set an attribute with the ResourceResolver doesn't make sense in every case. To be honest I think the only reason to do this is to get a better performance because the JCR session can be reused. But what if the authentication process has nothing to do with the JCR, what if someone authenticate to a separate system. It would be possible to use Sling in that case, but the implementation of the AuthenticationSupport has to allocate an ResourveResolver which should be the work of the new ResourceResolverFactory ([1]). That doesn't mean that the implementation AuthenticationSupport can not put a ResourceResolver or whatever as an attribute in the context, but it shouldn't forced to do so. AuthenticationSupport should only be responsible to put some basic information about the authentication into the context (like username, userid, authtype). Maybe I haven't get the idea right: If we implement not only the AuthenticationSupport but also the ResourceResolverFactory [1], why should the implementation of AuthenticationSupport select and call the ResourceResolverFactory to get an ResourceResolver and put it into the context? Can't we decouple the authentication completely from the getting of a ResourceResolver? I think to couple these two things adds not necessary complexity without adding additional possabilities. Wouldn't that also solve the problem with the unattractive endRequest, because in this case the Sling engine, which would get the ResourceResolver, would be in charge to call the close method which could logout the session or whatever. To solve the performance issue an AuthenticationSupport can put an context attribute with the ResourceResolver and the ResourceResolverFactory can pick up that ResourceResolver. In that case the getResourceResolver method on ResourceResolverFactory maybe should also get the HttpServletRequest. If the ResourceResolverFactory doesn't pick up the ResourceResolver we must find a way to logout the JCR session. Maybe by a ServletContextAttributeListener or the finalize() method. best regards mike [1] http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
