> In addition the AuthenticationSupport class has two safety nets to > ensure the ResourceResolver (and underlying repository connections such > as JCR Sessions or JDBC Connections) are released: (1) Implements and > registers ServletRequestListener (requires support by the Http Service > implementation, see FELIX-1962) and (2) implements a finalize() method > as a fallback if ServiceRequestListener mechanism is not readily available.
I wonder if the second safety net doesn't cause more trouble then it is worth. In Java Concurrency In Practice, Brian Goetz recommends to avoid using finalizers[1] for several reasons, stating only a single exception: releasing resources acquired by native methods. Furthermore, both Brian Goetz and Kas Thomas in a blog post[2] mention that there is no guarantee that the finalize method gets called at all. Regards Julian [1] http://book.javanb.com/java-concurrency-in-Practice/ch07lev1sec4.html#title-IDAW44TX [2] http://asserttrue.blogspot.com/2008/11/finalization-is-evil.html On Sat, Jan 2, 2010 at 1:46 PM, Felix Meschberger <fmesc...@gmail.com> wrote: > Hi, > > On 31.12.2009 14:49, Mike Müller wrote: >> 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. > > Conceptionaally, this is correct, and I agree -- and from the bottom of > my conceptionally correct heart, we would have to do this, but .... > >> To be honest I think the only reason to do this is to get a better >> performance because the JCR session can be reused. > > Performance is one aspect in this equation (a very important one, > though). Another aspect is, that the authentication handlers extract > credentials from the request which are used (a) to validate the > requestor's identity and (b) to actually get access to the > system/repository. > > If we go conceptionally clean, we would have to extract credentials > twice (duplicate implementation ? multiple uses of the same > implementations ? how ?). So we would probably end with an even bigger > "mess". > >> 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). > > Yes and/or now. Yet, Sling is centered around having a ResourceResolver > available to process requests. So it is IMHO ok for the > AuthenticationSupport class to not only handle credential extraction but > also provisioning of the ResourceResolver to be used for request handling. > > As such this is an extension to the HttpContext.handleSecurity > specification, which mandates the user name, authentication type and > (optionally) the OSGi Authorization object. > >> >> 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. > > Yes, while creating other problems ... > > Of course we could specify the AuthenticationSupport class to provide a > credentials map to be used with the new ResourceResolverFactory. But to > what avail ? Why not return the ResourceResolver directly ? > >> 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. > > I already abandone the "endRequest" idea already ... > >> >> 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. > > This is what is currently done: The AuthenticationSupport service places > the ResourceResolver to be used by the request as a request attribute > (replacing the Session which is currently set as a request attribute for > this purpose). > > In addition the AuthenticationSupport class has two safety nets to > ensure the ResourceResolver (and underlying repository connections such > as JCR Sessions or JDBC Connections) are released: (1) Implements and > registers ServletRequestListener (requires support by the Http Service > implementation, see FELIX-1962) and (2) implements a finalize() method > as a fallback if ServiceRequestListener mechanism is not readily available. > > Regards > Felix > >> >> best regards >> mike >> >> [1] >> http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html > >
