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
