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 >
