>From memory, cglib was always an optional dependency for blueprint. Originally used only for the proxying in service references, if cglib wasn't available, then that proxying would fall back to jdk proxy if possible. (Although, only cglib provided 'class proxying' support)
Later, it was also used to provide interceptors, again written to allow it to be optional, if it wasn't available, interceptor support would disable. Later still, we added the code to allow interceptors to utilise asm, (or cglib). We also have a jira open to common up our proxying code to a single place, to allow both interceptors and service reference proxying to share the code, and ideally provide an api to allow namespace handlers, bean processors implementations etc, to make use of the function. If the proxying code were to move out to its own bundle, then the cglib/asm/etc dependencies for proxying would be isolated to just there. Ozzy. On 6 April 2010 20:51, Joe Bohn <[email protected]> wrote: > > In discussion below regarding cglib .... was the intent to completely > remove the use of cglib or just make it optional? > > From what I can tell it seems that cglib is already optional (perhaps due > to changes after this discussion). But we still use it if available in > Blueprint AbstractServiceReference and the Blueprint Interceptor logic. If > we completely remove it from the Blueprint Interceptor logic we would always > assume ASM. If we completely remove it from AbstractServiceReference we > would always use the JdkProxy and would likewise need to remove the > AbstractServiceReferenceTest which seems to be cglib specific. > > I have some local changes that I can check in to completely remove cglib if > that is really the intent. > > Joe > > > > Jeremy Hughes wrote: > >> On 11 March 2010 15:48, Jeremy Hughes <[email protected]> wrote: >> >>> On 11 March 2010 14:59, Guillaume Nodet <[email protected]> wrote: >>> >>>> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <[email protected]> >>>> wrote: >>>> >>> > <snip/> > > > Beyong the core JRE and osgi packages, we have: >>>> * cglib : we should get rid of that one >>>> >>> +1 there's a few JIRAs around this but not one to get rid. >>> >> > <snip/> > > > We should really get rid of cglib asap. cglib itself uses asm and we >>>> have our own layer on top of asm. >>>> I don't think we should have a mandatory import on >>>> org.osgi.service.cm, so either find a way to make it optional or >>>> exclude it ? >>>> >>> ok >>> >> > <snip/> >
