So I agree if there is no need to proxy the service we shouldn't do it. In general you should only pay for it if you use it.
Not sure I follow your disagreement, but I suspect I just don't know enough about your scenario. Alasdair On 30 September 2010 11:52, Guillaume Nodet <[email protected]> wrote: > 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 > -- Alasdair Nottingham [email protected]
