Yeah, I haven't looked at the JNDI code recently. I know you've been working on it lately, but it sounds like a good idea to share those bits.
On Mon, Sep 27, 2010 at 07:56, Alasdair Nottingham <[email protected]> wrote: > Hi, > > Couple of things the JNDI code uses CGLib for parodying, I guess we should > also be using ASM. I'm also wondering if it makes sense for JNDI and > blueprint should share damping code, at the least the proxy generation could > be common, what do you think? > > Alasdair > > Alasdair Nottingham > > On 26 Sep 2010, at 22:09, Guillaume Nodet <[email protected]> wrote: > > > Btw, i've raised and fixed ARIES-427 for that, so the next release will > have no dependencies on cglib, and the blueprint bundle includes the needed > asm classes, so that it has no dependencies beyong slf4j and the osgi > packages. > > > > On Sun, Sep 26, 2010 at 19:40, Bengt Rodehav <[email protected]> wrote: > > Not sure I follow you Guillaume. > > > > How do I ensure that cglib is "present" when Blueprint resolves? What I > did was to add the following line to Karaf's startup.properties: > > > > > org/apache/servicemix/bundles/org.apache.servicemix.bundles.cglib/2.1_3_4/org.apache.servicemix.bundles.cglib-2.1_3_4.jar=12 > > > > It worked, but maybe that was by accident. What is the proper way to do > it? > > > > /Bengt > > > > 2010/9/26 Guillaume Nodet <[email protected]> > > Start level won't help in that case. The start level is for starting > bundles, not resolving them. The resolution will be done if the bundle is > present, so your behavior can only happen the first time you install gclib > *after* blueprint. > > > > > > On Sun, Sep 26, 2010 at 11:09, Bengt Rodehav <[email protected]> wrote: > > OK - sounds like you have a plan. I'm not that familiar with asm vs cglib > and therefore don't know why this problem would go away if you switched from > cglib to asm. > > > > Another way is, of course, to use OSGi services for this as well. I can > well imagine a "Byte code manipulator service". However you'd have to > encapsulate both asm and cglib behind a common interface. > > > > Meanwhile, I'll make sure that the cglib bundle's startlevel is lower > than Aries Blueprint... > > > > /Bengt > > > > 2010/9/26 Guillaume Nodet <[email protected]> > > > > A trick is to use both an optional import + a dynamic import without a > star... That way the dynamic stuff isn't too 'icky' ... > > Anyway, i agree to try getting rid of cglib. > > > > > > On Sun, Sep 26, 2010 at 08:41, Johan Edstrom <[email protected]> wrote: > > As an outside spectator that does a lot of osgi,getting rid of cglib > would be great. > > Dynamic imports are kinda "ICK" > > > > > > /je > > > > On Sep 26, 2010, at 12:35 AM, Guillaume Nodet wrote: > > > > > That's not the way it works in OSGi. This is true for services, not so > much for packages. There are ways to improve that by using a > DynamicImport-Package though ... > > > Anyway, I think we should use asm instead of cglib for proxying, as > it's done for interceptors. We get then get rid of cglib and only depend on > asm when needed. All the code is already available afaik. > > > > > > > > > On Sun, Sep 26, 2010 at 03:48, Bengt Rodehav <[email protected]> > wrote: > > > That will work but I regard this as a bug in Blueprint. A well behaved > OSGi citizen should keep track of dependencies coming and going. It > shouldn't matter if cglib was not present when Blueprint was started as long > as its there when it's needed (in this case when creating my blueprint > container that requires interceptors). > > > > > > Should I create a JIRA for this? > > > > > > /Bengt > > > > > > 2010/9/25 Guillaume Nodet <[email protected]> > > > > > > Try to restart or osgi:refresh the blueprint bundle in case the wiring > hasn't been correctly done. > > > > > > > > > On Sat, Sep 25, 2010 at 18:11, Bengt Rodehav <[email protected]> > wrote: > > > It seems like the Aries Blueprint bundle requires cglib (or asm) to be > installed before Blueprint is activated. If I first install Blueprint, then > cglib and then my bundle requiring transaction interceptors it fails with > with following exception: > > > > > > 2010-09-25 18:10:24,998 | ERROR | rint Extender: 2 | > BlueprintContainerImpl | container.BlueprintContainerImpl 342 | > Unable to start blueprint container for bundle refdata > > > org.osgi.service.blueprint.container.ComponentDefinitionException: > Interceptors have been configured but neither asm nor cglib are available > > > at > org.apache.aries.blueprint.container.BeanRecipe.addInterceptors(BeanRecipe.java:694)[7:org.apache.aries.blueprint:0.2.0.incubating] > > > at > org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:748)[7:org.apache.aries.blueprint:0.2.0.incubating] > > > at > org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[7:org.apache.aries.blueprint:0.2.0.incubating] > > > at > org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219)[7:org.apache.aries.blueprint:0.2.0.incubating] > > > at > org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:147)[7:org.apache.aries.blueprint:0.2.0.incubating] > > > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:624)[7:org.apache.aries.blueprint:0.2.0.incubating] > > > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:315)[7:org.apache.aries.blueprint:0.2.0.incubating] > > > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:213)[7:org.apache.aries.blueprint:0.2.0.incubating] > > > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_18] > > > at > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_18] > > > at > java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_18] > > > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_18] > > > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)[:1.6.0_18] > > > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_18] > > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_18] > > > at java.lang.Thread.run(Thread.java:619)[:1.6.0_18] > > > Caused by: java.lang.ClassNotFoundException: > net.sf.cglib.proxy.Enhancer > > > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:772)[org.apache.felix.framework-3.0.2.jar:] > > > at > org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73)[org.apache.felix.framework-3.0.2.jar:] > > > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1690)[org.apache.felix.framework-3.0.2.jar:] > > > at > java.lang.ClassLoader.loadClass(ClassLoader.java:248)[:1.6.0_18] > > > at > org.apache.aries.blueprint.container.BeanRecipe.addInterceptors(BeanRecipe.java:691)[7:org.apache.aries.blueprint:0.2.0.incubating] > > > ... 15 more > > > > > > > > > If I make sure that cglib is started before Blueprint then everything > works. Shouldn't it be enough that cglib is installed by the time I install > my bundle requiring interceptors. Blueprint should pick up cglib when it is > installed even if it happens after Blueprint itself is started. > > > > > > I use Karaf 2.1, Aries 0.2-incubating and the Servicemix packaging of > cglib version 2.1_3_4. > > > > > > /Bengt > > > > > > > > > > > > -- > > > Cheers, > > > Guillaume Nodet > > > ------------------------ > > > Blog: http://gnodet.blogspot.com/ > > > ------------------------ > > > Open Source SOA > > > http://fusesource.com > > > > > > > > > > > > > > > > > > > > > -- > > > Cheers, > > > Guillaume Nodet > > > ------------------------ > > > Blog: http://gnodet.blogspot.com/ > > > ------------------------ > > > Open Source SOA > > > http://fusesource.com > > > > > > > > > > Johan Edstrom > > > > [email protected] > > > > They that can give up essential liberty to purchase a little temporary > safety, deserve neither liberty nor safety. > > > > Benjamin Franklin, Historical Review of Pennsylvania, 1759 > > > > > > > > > > > > > > > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > > > > > > > > > > > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > > > > > > > > > > > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > > > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
