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
