You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Bengt Rodehav <be...@rodehav.com> on 2010/09/25 18:11:12 UTC
Aries Blueprint and cglib
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
Re: Aries Blueprint and cglib
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@gmail.com> 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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org>
>> 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 <gn...@gmail.com> 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 <no...@apache.org>
>> >> 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 <gn...@gmail.com> 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 <not@apache.org
>> >
>> >> >> 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 <gn...@gmail.com>
>> 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 <
>> not@apache.org>
>> >> >> >> 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 <gn...@gmail.com>
>> >> 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 <
>> bengt@rodehav.com>
>> >> >> >> 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 <gn...@gmail.com>
>> >> >> >>>>> 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 <
>> bengt@rodehav.com>
>> >> >> >> 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 <gn...@gmail.com>
>> >> >> >>>>>
>> >> >> >>>>> 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 <
>> seijoed@gmail.com>
>> >> >> >> 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 <
>> bengt@rodehav.com>
>> >> >> >>>> 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 <gn...@gmail.com>
>> >> >> >>>>>>
>> >> >> >>>>>> 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 <
>> bengt@rodehav.com>
>> >> >> >>>> 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
>> >> >> >>>>>
>> >> >> >>>>> joed@opennms.org
>> >> >> >>>>>
>> >> >> >>>>> 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
>> >> not@apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Cheers,
>> > Guillaume Nodet
>> > ------------------------
>> > Blog: http://gnodet.blogspot.com/
>> > ------------------------
>> > Open Source SOA
>> > http://fusesource.com
>> >
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: Aries Blueprint and cglib
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org>
> 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 <gn...@gmail.com> 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 <no...@apache.org>
> >> 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 <gn...@gmail.com> 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 <not@apache.org
> >
> >> >> 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 <gn...@gmail.com>
> 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 <
> not@apache.org>
> >> >> >> 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 <gn...@gmail.com>
> >> 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 <
> bengt@rodehav.com>
> >> >> >> 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 <gn...@gmail.com>
> >> >> >>>>> 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 <
> bengt@rodehav.com>
> >> >> >> 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 <gn...@gmail.com>
> >> >> >>>>>
> >> >> >>>>> 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 <
> seijoed@gmail.com>
> >> >> >> 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 <
> bengt@rodehav.com>
> >> >> >>>> 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 <gn...@gmail.com>
> >> >> >>>>>>
> >> >> >>>>>> 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 <
> bengt@rodehav.com>
> >> >> >>>> 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
> >> >> >>>>>
> >> >> >>>>> joed@opennms.org
> >> >> >>>>>
> >> >> >>>>> 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
> >> not@apache.org
> >>
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Aries Blueprint and cglib
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@gmail.com> 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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org>
>> 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 <gn...@gmail.com> 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 <no...@apache.org>
>> >> 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 <gn...@gmail.com> 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 <no...@apache.org>
>> >> >> 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 <gn...@gmail.com>
>> 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 <be...@rodehav.com>
>> >> >> 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 <gn...@gmail.com>
>> >> >>>>> 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 <be...@rodehav.com>
>> >> >> 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 <gn...@gmail.com>
>> >> >>>>>
>> >> >>>>> 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 <se...@gmail.com>
>> >> >> 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 <be...@rodehav.com>
>> >> >>>> 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 <gn...@gmail.com>
>> >> >>>>>>
>> >> >>>>>> 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 <be...@rodehav.com>
>> >> >>>> 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
>> >> >>>>>
>> >> >>>>> joed@opennms.org
>> >> >>>>>
>> >> >>>>> 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
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: Aries Blueprint and cglib
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org>
> 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 <gn...@gmail.com> 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 <no...@apache.org>
> >> 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 <gn...@gmail.com> 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 <no...@apache.org>
> >> >> 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 <gn...@gmail.com>
> 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 <be...@rodehav.com>
> >> >> 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 <gn...@gmail.com>
> >> >>>>> 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 <be...@rodehav.com>
> >> >> 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 <gn...@gmail.com>
> >> >>>>>
> >> >>>>> 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 <se...@gmail.com>
> >> >> 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 <be...@rodehav.com>
> >> >>>> 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 <gn...@gmail.com>
> >> >>>>>>
> >> >>>>>> 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 <be...@rodehav.com>
> >> >>>> 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
> >> >>>>>
> >> >>>>> joed@opennms.org
> >> >>>>>
> >> >>>>> 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
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Aries Blueprint and cglib
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@gmail.com> 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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org>
>> 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 <gn...@gmail.com> 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 <no...@apache.org>
>> >> 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 <gn...@gmail.com> 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 <be...@rodehav.com>
>> >> 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 <gn...@gmail.com>
>> >>>>> 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 <be...@rodehav.com>
>> >> 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 <gn...@gmail.com>
>> >>>>>
>> >>>>> 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 <se...@gmail.com>
>> >> 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 <be...@rodehav.com>
>> >>>> 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 <gn...@gmail.com>
>> >>>>>>
>> >>>>>> 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 <be...@rodehav.com>
>> >>>> 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
>> >>>>>
>> >>>>> joed@opennms.org
>> >>>>>
>> >>>>> 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
not@apache.org
Re: Aries Blueprint and cglib
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org>
> 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 <gn...@gmail.com> 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 <no...@apache.org>
> >> 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 <gn...@gmail.com> 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 <be...@rodehav.com>
> >> 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 <gn...@gmail.com>
> >>>>> 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 <be...@rodehav.com>
> >> 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 <gn...@gmail.com>
> >>>>>
> >>>>> 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 <se...@gmail.com>
> >> 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 <be...@rodehav.com>
> >>>> 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 <gn...@gmail.com>
> >>>>>>
> >>>>>> 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 <be...@rodehav.com>
> >>>> 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
> >>>>>
> >>>>> joed@opennms.org
> >>>>>
> >>>>> 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
Re: Aries Blueprint and cglib
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@gmail.com> 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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org>
>> 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 <gn...@gmail.com> 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 <be...@rodehav.com>
>> 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 <gn...@gmail.com>
>>>>> 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 <be...@rodehav.com>
>> 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 <gn...@gmail.com>
>>>>>
>>>>> 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 <se...@gmail.com>
>> 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 <be...@rodehav.com>
>>>> 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 <gn...@gmail.com>
>>>>>>
>>>>>> 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 <be...@rodehav.com>
>>>> 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
>>>>>
>>>>> joed@opennms.org
>>>>>
>>>>> 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
Re: Aries Blueprint and cglib
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <no...@apache.org> 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 <gn...@gmail.com> 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 <no...@apache.org>
> 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 <gn...@gmail.com> 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 <be...@rodehav.com>
> 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 <gn...@gmail.com>
> >>> 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 <be...@rodehav.com>
> 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 <gn...@gmail.com>
> >>>
> >>> 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 <se...@gmail.com>
> 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 <be...@rodehav.com>
> >> 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 <gn...@gmail.com>
> >>>>
> >>>> 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 <be...@rodehav.com>
> >> 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
> >>>
> >>> joed@opennms.org
> >>>
> >>> 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
Re: Aries Blueprint and cglib
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@gmail.com> 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 <no...@apache.org> 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 <gn...@gmail.com> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
>>> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
>>>
>>> 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 <se...@gmail.com> 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 <be...@rodehav.com>
>> 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 <gn...@gmail.com>
>>>>
>>>> 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 <be...@rodehav.com>
>> 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
>>>
>>> joed@opennms.org
>>>
>>> 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
Re: Aries Blueprint and cglib
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <no...@apache.org> 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 <gn...@gmail.com> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
> > 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 <be...@rodehav.com> 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 <gn...@gmail.com>
> >
> > 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 <se...@gmail.com> 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 <be...@rodehav.com>
> 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 <gn...@gmail.com>
> > >
> > > 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 <be...@rodehav.com>
> 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
> >
> > joed@opennms.org
> >
> > 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
Re: Aries Blueprint and cglib
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@gmail.com> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
>
> 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 <se...@gmail.com> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
> >
> > 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 <be...@rodehav.com> 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
>
> joed@opennms.org
>
> 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
>
>
Re: Aries Blueprint and cglib
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <be...@rodehav.com> 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 <gn...@gmail.com>
>
>> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
>>>
>>> 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 <se...@gmail.com> 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 <be...@rodehav.com>
>>>>> 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 <gn...@gmail.com>
>>>>> >
>>>>> > 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 <be...@rodehav.com>
>>>>> 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
>>>>>
>>>>> joed@opennms.org
>>>>>
>>>>> 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
Re: Aries Blueprint and cglib
Posted by Bengt Rodehav <be...@rodehav.com>.
OK - thanks,
/Bengt
2010/9/26 Guillaume Nodet <gn...@gmail.com>
> Bundles installed as part of features will be installed and started later
> in the process, so i think this would lead to the behavior you've seen.
> Though, upon features installation, i thought the blueprint bundle would
> have been refreshed ...
> But hacking the startup.properties file is fine, I just wanted to point
> that the bundle level has nothing to do with that.
>
> On Sun, Sep 26, 2010 at 22:01, Bengt Rodehav <be...@rodehav.com> wrote:
>
>> OK. But what about bundles being installed and started as Karaf features?
>> I think that's where I put cglib first?
>>
>> /Bengt
>>
>> 2010/9/26 Guillaume Nodet <gn...@gmail.com>
>>
>>> I'll work, but would you use 90 instead of 12, it work work too. The
>>> reason is that karaf will install all bundles before starting any of those.
>>> So when the osgi framework try to resolve the blueprint bundle, it will
>>> first resolve the cglib one. You don't even have to start to cglib bundle
>>> for everything to work.
>>>
>>>
>>> On Sun, Sep 26, 2010 at 19:40, Bengt Rodehav <be...@rodehav.com> 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 <gn...@gmail.com>
>>>>
>>>>> 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 <be...@rodehav.com>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 <gn...@gmail.com>
>>>>>>
>>>>>> 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 <se...@gmail.com>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 <be...@rodehav.com>
>>>>>>>> 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 <gn...@gmail.com>
>>>>>>>> >
>>>>>>>> > 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 <be...@rodehav.com>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> joed@opennms.org
>>>>>>>>
>>>>>>>> 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
>
>
>
Re: Aries Blueprint and cglib
Posted by Guillaume Nodet <gn...@gmail.com>.
Bundles installed as part of features will be installed and started later in
the process, so i think this would lead to the behavior you've seen.
Though, upon features installation, i thought the blueprint bundle would
have been refreshed ...
But hacking the startup.properties file is fine, I just wanted to point that
the bundle level has nothing to do with that.
On Sun, Sep 26, 2010 at 22:01, Bengt Rodehav <be...@rodehav.com> wrote:
> OK. But what about bundles being installed and started as Karaf features? I
> think that's where I put cglib first?
>
> /Bengt
>
> 2010/9/26 Guillaume Nodet <gn...@gmail.com>
>
>> I'll work, but would you use 90 instead of 12, it work work too. The
>> reason is that karaf will install all bundles before starting any of those.
>> So when the osgi framework try to resolve the blueprint bundle, it will
>> first resolve the cglib one. You don't even have to start to cglib bundle
>> for everything to work.
>>
>>
>> On Sun, Sep 26, 2010 at 19:40, Bengt Rodehav <be...@rodehav.com> 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 <gn...@gmail.com>
>>>
>>>> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
>>>>>
>>>>> 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 <se...@gmail.com>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 <be...@rodehav.com>
>>>>>>> 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 <gn...@gmail.com>
>>>>>>> >
>>>>>>> > 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 <be...@rodehav.com>
>>>>>>> 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
>>>>>>>
>>>>>>> joed@opennms.org
>>>>>>>
>>>>>>> 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
Re: Aries Blueprint and cglib
Posted by Bengt Rodehav <be...@rodehav.com>.
OK. But what about bundles being installed and started as Karaf features? I
think that's where I put cglib first?
/Bengt
2010/9/26 Guillaume Nodet <gn...@gmail.com>
> I'll work, but would you use 90 instead of 12, it work work too. The
> reason is that karaf will install all bundles before starting any of those.
> So when the osgi framework try to resolve the blueprint bundle, it will
> first resolve the cglib one. You don't even have to start to cglib bundle
> for everything to work.
>
>
> On Sun, Sep 26, 2010 at 19:40, Bengt Rodehav <be...@rodehav.com> 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 <gn...@gmail.com>
>>
>>> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
>>>>
>>>> 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 <se...@gmail.com>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 <be...@rodehav.com>
>>>>>> 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 <gn...@gmail.com>
>>>>>> >
>>>>>> > 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 <be...@rodehav.com>
>>>>>> 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
>>>>>>
>>>>>> joed@opennms.org
>>>>>>
>>>>>> 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
>
>
>
Re: Aries Blueprint and cglib
Posted by Guillaume Nodet <gn...@gmail.com>.
I'll work, but would you use 90 instead of 12, it work work too. The reason
is that karaf will install all bundles before starting any of those. So
when the osgi framework try to resolve the blueprint bundle, it will first
resolve the cglib one. You don't even have to start to cglib bundle for
everything to work.
On Sun, Sep 26, 2010 at 19:40, Bengt Rodehav <be...@rodehav.com> 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 <gn...@gmail.com>
>
>> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
>>>
>>> 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 <se...@gmail.com> 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 <be...@rodehav.com>
>>>>> 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 <gn...@gmail.com>
>>>>> >
>>>>> > 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 <be...@rodehav.com>
>>>>> 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
>>>>>
>>>>> joed@opennms.org
>>>>>
>>>>> 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
Re: Aries Blueprint and cglib
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@gmail.com>
> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
>>
>> 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 <se...@gmail.com> 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 <be...@rodehav.com>
>>>> 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 <gn...@gmail.com>
>>>> >
>>>> > 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 <be...@rodehav.com>
>>>> 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
>>>>
>>>> joed@opennms.org
>>>>
>>>> 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
>
>
>
Re: Aries Blueprint and cglib
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <be...@rodehav.com> 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 <gn...@gmail.com>
>
> 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 <se...@gmail.com> 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 <be...@rodehav.com>
>>> 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 <gn...@gmail.com>
>>> >
>>> > 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 <be...@rodehav.com>
>>> 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
>>>
>>> joed@opennms.org
>>>
>>> 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
Re: Aries Blueprint and cglib
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@gmail.com>
> 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 <se...@gmail.com> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
>> >
>> > 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 <be...@rodehav.com> 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
>>
>> joed@opennms.org
>>
>> 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
>
>
>
Re: Aries Blueprint and cglib
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <se...@gmail.com> 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 <be...@rodehav.com> 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 <gn...@gmail.com>
> >
> > 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 <be...@rodehav.com> 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
>
> joed@opennms.org
>
> 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
Re: Aries Blueprint and cglib
Posted by Johan Edstrom <se...@gmail.com>.
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 <be...@rodehav.com> 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 <gn...@gmail.com>
>
> 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 <be...@rodehav.com> 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
joed@opennms.org
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
Re: Aries Blueprint and cglib
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <be...@rodehav.com> 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 <gn...@gmail.com>
>
> 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 <be...@rodehav.com> 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
Re: Aries Blueprint and cglib
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <gn...@gmail.com>
> 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 <be...@rodehav.com> 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
>
>
>
Re: Aries Blueprint and cglib
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <be...@rodehav.com> 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