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
