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 >> >
