Hi, Yes, I know and (partly) agree with them. This is why the finalize() method is only a second-level measure. The primary measure to ensure sessions are logged out is the RequestEventListener which cleans up after the request.
Regards Felix On 02.01.2010 15:55, Julian Sedding wrote: >> 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 <[email protected]> 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/%[email protected]%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 >> >> >
