I agree we should not bend the design if not needed. However, removing potential problems that our users might run into is a good goal. I'm also wondering the need to create a proxy at all if the quiesce thingy isn't used (which mean if the quiesce api is not wired). In that case, we could (should ?) expose the real object instead of wrapping it.
Also I somewhat disagree about your analysis. The client side supports greedy proxying on collections, which won't work if we only expose a jdk proxy. Well, it will work, but really brings nothing... On Thu, Sep 30, 2010 at 12:08, Alasdair Nottingham <[email protected]> wrote: > 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] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
