Re: Deprecating JcrResource.adaptTo(URL) ?
Hi Justin, thanks for the work. I guess it's fine if we don't mark the url adaption as deprecated in the console. There will still be the log entry. I guess/hope noone is using this anyway :) In order to get the deprecation info into the console, what do we need to release? Regards Carsten 2014-08-21 15:31 GMT+02:00 Justin Edelson jus...@justinedelson.com: Ugh. I realized this one is a bit more complicated to deprecate in the way I was thinking. JcrResource.adaptTo(URL.class) is implemented as an adaptation within JcrResource along with several others. I was thinking that we would flag the whole adapter factory as deprecated. I don't see a practical way to mark a single adapation within an adaptable or an adapter factory as deprecated. Sigh... On Thu, Aug 21, 2014 at 7:19 AM, Jeff Young j...@adobe.com wrote: +1 (to deprecating adaptTo(URL), and to deprecation comments in the other thread) Cheers, Jeff. On 20/08/2014 17:29, Justin Edelson jus...@justinedelson.com wrote: Hi, I'm fine with this, although I'm see my other email about what it means to deprecate an adapter factory. Justin On Wed, Aug 20, 2014 at 11:59 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi, the JCR Resource implementation currently allows to adapt it to a url which internally embeds several jackrabbit classes. The returned object keeps hold of the current session and therefore is a potential memory leak and can't be used once the session is closed. So far I've not seen any real use case for this and especially as other resource implementations do not provide it, what about deprecating this now, logging a big message when used (once) and then we can remove it in one of the next versions? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Deprecating JcrResource.adaptTo(URL) ?
Hi Carsten, In order to get the deprecation info into the console, what do we need to release? The adapter bundle. You can add the deprecation flag to adapters without this release, of course, it'll just be ignored. Justin On Fri, Aug 22, 2014 at 11:59 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi Justin, thanks for the work. I guess it's fine if we don't mark the url adaption as deprecated in the console. There will still be the log entry. I guess/hope noone is using this anyway :) In order to get the deprecation info into the console, what do we need to release? Regards Carsten 2014-08-21 15:31 GMT+02:00 Justin Edelson jus...@justinedelson.com: Ugh. I realized this one is a bit more complicated to deprecate in the way I was thinking. JcrResource.adaptTo(URL.class) is implemented as an adaptation within JcrResource along with several others. I was thinking that we would flag the whole adapter factory as deprecated. I don't see a practical way to mark a single adapation within an adaptable or an adapter factory as deprecated. Sigh... On Thu, Aug 21, 2014 at 7:19 AM, Jeff Young j...@adobe.com wrote: +1 (to deprecating adaptTo(URL), and to deprecation comments in the other thread) Cheers, Jeff. On 20/08/2014 17:29, Justin Edelson jus...@justinedelson.com wrote: Hi, I'm fine with this, although I'm see my other email about what it means to deprecate an adapter factory. Justin On Wed, Aug 20, 2014 at 11:59 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi, the JCR Resource implementation currently allows to adapt it to a url which internally embeds several jackrabbit classes. The returned object keeps hold of the current session and therefore is a potential memory leak and can't be used once the session is closed. So far I've not seen any real use case for this and especially as other resource implementations do not provide it, what about deprecating this now, logging a big message when used (once) and then we can remove it in one of the next versions? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Deprecating JcrResource.adaptTo(URL) ?
+1 (to deprecating adaptTo(URL), and to deprecation comments in the other thread) Cheers, Jeff. On 20/08/2014 17:29, Justin Edelson jus...@justinedelson.com wrote: Hi, I'm fine with this, although I'm see my other email about what it means to deprecate an adapter factory. Justin On Wed, Aug 20, 2014 at 11:59 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi, the JCR Resource implementation currently allows to adapt it to a url which internally embeds several jackrabbit classes. The returned object keeps hold of the current session and therefore is a potential memory leak and can't be used once the session is closed. So far I've not seen any real use case for this and especially as other resource implementations do not provide it, what about deprecating this now, logging a big message when used (once) and then we can remove it in one of the next versions? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Deprecating JcrResource.adaptTo(URL) ?
Ugh. I realized this one is a bit more complicated to deprecate in the way I was thinking. JcrResource.adaptTo(URL.class) is implemented as an adaptation within JcrResource along with several others. I was thinking that we would flag the whole adapter factory as deprecated. I don't see a practical way to mark a single adapation within an adaptable or an adapter factory as deprecated. Sigh... On Thu, Aug 21, 2014 at 7:19 AM, Jeff Young j...@adobe.com wrote: +1 (to deprecating adaptTo(URL), and to deprecation comments in the other thread) Cheers, Jeff. On 20/08/2014 17:29, Justin Edelson jus...@justinedelson.com wrote: Hi, I'm fine with this, although I'm see my other email about what it means to deprecate an adapter factory. Justin On Wed, Aug 20, 2014 at 11:59 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi, the JCR Resource implementation currently allows to adapt it to a url which internally embeds several jackrabbit classes. The returned object keeps hold of the current session and therefore is a potential memory leak and can't be used once the session is closed. So far I've not seen any real use case for this and especially as other resource implementations do not provide it, what about deprecating this now, logging a big message when used (once) and then we can remove it in one of the next versions? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Deprecating JcrResource.adaptTo(URL) ?
Hi, I'm fine with this, although I'm see my other email about what it means to deprecate an adapter factory. Justin On Wed, Aug 20, 2014 at 11:59 AM, Carsten Ziegeler cziege...@apache.org wrote: Hi, the JCR Resource implementation currently allows to adapt it to a url which internally embeds several jackrabbit classes. The returned object keeps hold of the current session and therefore is a potential memory leak and can't be used once the session is closed. So far I've not seen any real use case for this and especially as other resource implementations do not provide it, what about deprecating this now, logging a big message when used (once) and then we can remove it in one of the next versions? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
