Re losing anything, Off the top of my head, I don't know, but Valentin mentioned that cglib handled multiple interface proxying where the asm alternative didn't..
If we only want a single implementation to lighten the test/support load, that's fine =) However, I'd still like it to be abstracted out / tidied up so it can be made use of by BeanProcessors & NamespaceHandlers (while also being used for both Interceptors and ServiceReferences). I guess it may also be beneficial to look a little deeper to find out what other differences there are in the capabilities of the two (ignoring jdk proxy here for a mo). Ozzy. On 7 April 2010 20:45, Jeremy Hughes <[email protected]> wrote: > On 7 April 2010 20:16, The Dweller <[email protected]> wrote: > > We built our interceptors based over asm (and over cglib).. I wouldn't > > consider the asm implementation as a lib currently, it has no external > api, > > and it is only used for interceptors. > > > > The suggestion isn't so much to keep cglib as being used, as to abstract > all > > our usage of cglib/asm/jdkproxy into a single place, so that its > > implementation is irrelevant. Then yes, it could be considered as our own > > proxying lib. At which point, it matters little if the implementation is > > handled via cglib, asm, or jdk proxy, each of which brings their own set > of > > advantages/disadvantages to the table. > > > > Is there something bad about having the proxying able to run on a variety > of > > libraries? > > I know this sounds nice but it means extra to test and support and > really I don't think the user is going care which is being used > underneath so long as it works as advertised. If we were to just ASM > and the code we have in Aries on top of that do we lose anything > (other than other dependency options to achieve the same)? > > > > > Ozzy. > > > > > > > > > > On 7 April 2010 19:59, Guillaume Nodet <[email protected]> wrote: > > > >> I must be missing something. I thought we built our own lib on top of > >> asm for the interceptors stuff. My point is that this lib looks kinda > >> like cglib, being built on top of asm. So why don't we use it instead > >> of cglib everywhere so that we can get rid of cglib? > >> > >> On Wednesday, April 7, 2010, Joe Bohn <[email protected]> wrote: > >> > > >> > So, if I understand you correctly then, your point is that we should > not > >> be looking to remove cglib completely but just keep it optional. It has > been > >> included in blueprint for a while (for service reference proxies) and we > >> have found it useful for other things like interceptors. We should keep > it > >> optional and consolidate it (along with asm) to a common bundle. > >> > > >> > Thanks, > >> > Joe > >> > > >> > > >> > The Dweller wrote: > >> > > >> > 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/> > >> > > >> > > >> > > >> > > >> > > >> > > >> > -- > >> > Joe > >> > > >> > >> -- > >> Cheers, > >> Guillaume Nodet > >> ------------------------ > >> Blog: http://gnodet.blogspot.com/ > >> ------------------------ > >> Open Source SOA > >> http://fusesource.com > >> > > >
