Your client code is broken. You shouldn't rely on a service implementing an interface or extending a class it isn't published using.
On 29 September 2010 07:00, Guillaume Nodet <[email protected]> wrote: > I just find Karaf a bit broken due to this behavior. I wonder if we should > use asm with subclass proxying by default (if asm is available) instead of > using a jdk proxy. I think making sure the real class is still available > would help reduce the possible problems. > In my cas, there was some code which was checking the class of an exported > service using instanceof, and that was broken due to the use of proxies. As > a workaround, it's possible to force the use of subclass proxies by using > auto-export="all-classes" on the service (which kinda makes sense in my > case). > Thoughts? > > On Mon, Sep 27, 2010 at 08:52, Alasdair Nottingham <[email protected]> wrote: > >> Before the 4.3 draft was published I would have said there is no issue. >> When 4.3 compendium is published one of the specs relies on reading >> annotations from the service implementation, so we need to make sure the >> proxy has the target classes annotations. >> >> Alasdair >> >> On 27 Sep 2010, at 07:37, Guillaume Nodet <[email protected]> wrote: >> >> > Btw, after having done the changes in blueprint, I hit one small (maybe?) >> > problem which I want to report and gather feedback on. >> > By default, the ServiceRecipe will add a quiesce interceptor on exported >> > services. That looks good, but it has the side effect of not exposing >> the >> > bean itself as a service, so I had to change the tests that were >> asserting >> > assertSame() to assertEquals(). I'm not sure if it has any consequence >> on >> > TCK or something like that, but I wanted to report it. >> > I think this problem was kinda hidden because in the tests, the asm lib >> was >> > not available, so interceptors were not configured at all (this also >> means >> > that the behavior was actually already present when asm was available). >> > >> > On Mon, Sep 27, 2010 at 08:27, Alasdair Nottingham <[email protected]> >> wrote: >> > >> >> I have indeed. I'm currently making changes which "improve" the way it >> >> handles services, but we will see what people think. After that I'll >> look at >> >> the proxying code. >> >> >> >> Alasdair >> >> >> >> Alasdair Nottingham >> >> >> >> On 27 Sep 2010, at 07:02, Guillaume Nodet <[email protected]> wrote: >> >> >> >>> 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 >> >> >> > >> > >> > >> > -- >> > 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 > -- Alasdair Nottingham [email protected]
