aries-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Aries Blueprint and cglib
Date Sun, 26 Sep 2010 09:23:39 GMT
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 <gnodet@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 <gnodet@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

Mime
View raw message