I'm sorry I disagree with this. OSGi is a modularity system, so when using it you should absolutely not be dependant on the implementation of a service. Code that does this is badly designed, not modular and not using OSGi correctly. I do not think we should be designing our code to take into account these kinds of clients.
I'm not expressing a view on whether we should use asm by default. I'm just saying this is a really poor reason for asking for the change. Alasdair On 30 September 2010 10:16, Guillaume Nodet <[email protected]> wrote: > Right, so that's why exporting all classes actaully fixes the probelm. But > what I meant is that people making mistakes is not a sufficient reason to > brake their code. > That doesn't change my remark: should we prefer using subclass proxies to > not disturb users ? Does it have any drawback? > > On Thu, Sep 30, 2010 at 11:10, Alasdair Nottingham <[email protected]> wrote: > >> 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] >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Alasdair Nottingham [email protected]
