You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Guillaume Yziquel <gu...@crossing-tech.com> on 2012/04/19 09:54:52 UTC
equinox/felix behaviour with lib/endorsed
Hi.
I've encountered a problem concerning different behaviours between
equinox and felix concerning jars in lib/endorsed (I'm using Karaf).
I've got a bundle A that depends on classes located in a .jar in
lib/endorsed. With equinox, the bundle A has no problems finding the
classes. With felix, these classes are not found.
Typical error messages I've found are:
09:50:39,041 | ERROR | rint Extender: 1 | BlueprintContainerImpl | ? ? | 10 - org.apache.aries.blueprint - 0.3.1 | Unable to start blueprint container for bundle my.bundle.A
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to instantiate components
at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:644)[10:org.apache.aries.blueprint:0.3.1]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:331)[10:org.apache.aries.blueprint:0.3.1]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:227)[10:org.apache.aries.blueprint:0.3.1]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_30]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_30]
at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_30]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_30]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_30]
at java.lang.Thread.run(Thread.java:662)[:1.6.0_30]
Caused by: java.lang.NoClassDefFoundError: my/missing/Class
at java.lang.Class.getDeclaredConstructors0(Native Method)[:1.6.0_30]
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)[:1.6.0_30]
at java.lang.Class.getConstructors(Class.java:1459)[:1.6.0_30]
at org.apache.aries.blueprint.container.BeanRecipe.findMatchingConstructors(BeanRecipe.java:439)[10:org.apache.aries.blueprint:0.3.1]
at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:263)[10:org.apache.aries.blueprint:0.3.1]
at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:706)[10:org.apache.aries.blueprint:0.3.1]
at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[10:org.apache.aries.blueprint:0.3.1]
at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219)[10:org.apache.aries.blueprint:0.3.1]
at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:147)[10:org.apache.aries.blueprint:0.3.1]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:640)[10:org.apache.aries.blueprint:0.3.1]
... 10 more
Caused by: java.lang.ClassNotFoundException: my.missing.Class not found by my.bundle.A [233]
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:845)
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:74)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1839)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_30]
... 20 more
I'd be interested in understanding more in details why behaviours
between felix and equinox are different on this point. Pointers to
documentation would be welcome.
--
Guillaume Yziquel
Crossing-Tech
Parc Scientifique EPFL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: equinox/felix behaviour with lib/endorsed
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/23/12 09:50 , Guillaume Yziquel wrote:
> Le Monday 23 Apr 2012 à 09:32:32 (-0400), Richard S. Hall a écrit :
>> I assume you mean with relevant exports (for system bundle) and
>> imports (in the bundle), then both work.
> Yes.
>
>> I think that is the correct behavior, no?
> Yes. I was surprised that equinox is less strict.
>
>> If it is not exported, then it should be visible, unless I'm
>> misunderstanding your scenario.
> I assume you meant 'not visible'. Equinox sees it even if not exported
> (in the system bundle). That's the behaviour I've been puzzled by.
Yes, I meant "not visible"...
I was under the impression that plain Equinox would be strict whereas
Equinox running in Eclipse would be less strict...
-> richard
>
>> -> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: equinox/felix behaviour with lib/endorsed
Posted by Guillaume Yziquel <gu...@crossing-tech.com>.
Le Monday 23 Apr 2012 à 09:32:32 (-0400), Richard S. Hall a écrit :
>
> I assume you mean with relevant exports (for system bundle) and
> imports (in the bundle), then both work.
Yes.
> I think that is the correct behavior, no?
Yes. I was surprised that equinox is less strict.
> If it is not exported, then it should be visible, unless I'm
> misunderstanding your scenario.
I assume you meant 'not visible'. Equinox sees it even if not exported
(in the system bundle). That's the behaviour I've been puzzled by.
> -> richard
--
Guillaume Yziquel
Crossing-Tech
Parc Scientifique EPFL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: equinox/felix behaviour with lib/endorsed
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/23/12 08:13 , Guillaume Yziquel wrote:
> Le Thursday 19 Apr 2012 à 09:38:55 (-0400), Richard S. Hall a écrit :
>> On 4/19/12 09:36 , Guillaume Yziquel wrote:
>>> Le Thursday 19 Apr 2012 à 09:32:27 (-0400), Richard S. Hall a écrit :
>>>> No.
>>>>
>>>> The main difference if you are running inside of Eclipse for
>>>> Equinox, then boot delegation will be automatically set. But if you
>>>> are using Equinox and Felix from the command line directly, then I'd
>>>> expect them to be pretty similar.
>>> Then, from what I see, if you put a .jar in lib/endorsed in a karaf
>>> framework, there is a difference: turning karaf.framework from equinox
>>> to felix does change the ability of a bundle to see the .jar in
>>> lib/endorsed. Not sure of why yet, or whether or not it is a karaf-only
>>> issue, but I do perceive a difference. Will dig into that. Thanks a lot.
>>>
>> Do this: Create a simple bundle that tries to access a lib endorsed
>> class. Then install and start it in plain Equinox and Felix and see
>> what happens.
> With relevant exports in custom.properties (the
> org.osgi.framework.system.packages.extra), both Equinox and Felix work
> fine. Without, only equinox works.
I assume you mean with relevant exports (for system bundle) and imports
(in the bundle), then both work.
I think that is the correct behavior, no?
If it is not exported, then it should be visible, unless I'm
misunderstanding your scenario.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: equinox/felix behaviour with lib/endorsed
Posted by Guillaume Yziquel <gu...@crossing-tech.com>.
Le Thursday 19 Apr 2012 à 09:38:55 (-0400), Richard S. Hall a écrit :
> On 4/19/12 09:36 , Guillaume Yziquel wrote:
> >Le Thursday 19 Apr 2012 à 09:32:27 (-0400), Richard S. Hall a écrit :
> >>No.
> >>
> >>The main difference if you are running inside of Eclipse for
> >>Equinox, then boot delegation will be automatically set. But if you
> >>are using Equinox and Felix from the command line directly, then I'd
> >>expect them to be pretty similar.
> >Then, from what I see, if you put a .jar in lib/endorsed in a karaf
> >framework, there is a difference: turning karaf.framework from equinox
> >to felix does change the ability of a bundle to see the .jar in
> >lib/endorsed. Not sure of why yet, or whether or not it is a karaf-only
> >issue, but I do perceive a difference. Will dig into that. Thanks a lot.
> >
>
> Do this: Create a simple bundle that tries to access a lib endorsed
> class. Then install and start it in plain Equinox and Felix and see
> what happens.
With relevant exports in custom.properties (the
org.osgi.framework.system.packages.extra), both Equinox and Felix work
fine. Without, only equinox works.
--
Guillaume Yziquel
Crossing-Tech
Parc Scientifique EPFL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: equinox/felix behaviour with lib/endorsed
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/19/12 09:36 , Guillaume Yziquel wrote:
> Le Thursday 19 Apr 2012 à 09:32:27 (-0400), Richard S. Hall a écrit :
>> No.
>>
>> The main difference if you are running inside of Eclipse for
>> Equinox, then boot delegation will be automatically set. But if you
>> are using Equinox and Felix from the command line directly, then I'd
>> expect them to be pretty similar.
> Then, from what I see, if you put a .jar in lib/endorsed in a karaf
> framework, there is a difference: turning karaf.framework from equinox
> to felix does change the ability of a bundle to see the .jar in
> lib/endorsed. Not sure of why yet, or whether or not it is a karaf-only
> issue, but I do perceive a difference. Will dig into that. Thanks a lot.
>
Do this: Create a simple bundle that tries to access a lib endorsed
class. Then install and start it in plain Equinox and Felix and see what
happens.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: equinox/felix behaviour with lib/endorsed
Posted by Guillaume Yziquel <gu...@crossing-tech.com>.
Le Thursday 19 Apr 2012 à 09:32:27 (-0400), Richard S. Hall a écrit :
>
> No.
>
> The main difference if you are running inside of Eclipse for
> Equinox, then boot delegation will be automatically set. But if you
> are using Equinox and Felix from the command line directly, then I'd
> expect them to be pretty similar.
Then, from what I see, if you put a .jar in lib/endorsed in a karaf
framework, there is a difference: turning karaf.framework from equinox
to felix does change the ability of a bundle to see the .jar in
lib/endorsed. Not sure of why yet, or whether or not it is a karaf-only
issue, but I do perceive a difference. Will dig into that. Thanks a lot.
--
Guillaume Yziquel
Crossing-Tech
Parc Scientifique EPFL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: equinox/felix behaviour with lib/endorsed
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/19/12 09:17 , Guillaume Yziquel wrote:
> Hi.
>
> Le Thursday 19 Apr 2012 à 09:07:47 (-0400), Richard S. Hall a écrit :
>> Is your bundle importing the package in question? If not, you should
>> import it in your bundle and then modify the system bundle to export
>> the package.
>>
>> If you don't want to import it (which is a bad idea), you could also
>> add that package to the framework's boot delegation property.
>>
>> The first option is the best.
>>
>> -> richard
> I tried the second option first. Didn't work out.
>
> I then tried the first option. I guess my problem is getting the system
> bundle to export the package properly, which is not the case as I can
> see from the karaf console.
>
> However, it seems that there is some mechanism in karaf about the two
> different config.properties and custom.properties to override one with
> the other. The exact mechanism is still unclear to me. But this maybe
> becomes a karaf question.
>
> As to equinox / felix comparison, is there some detailed explanation as
> to what the 'boot-time' differences precisely are? It seems many people
> get into this mismatch at one point or another.
No.
The main difference if you are running inside of Eclipse for Equinox,
then boot delegation will be automatically set. But if you are using
Equinox and Felix from the command line directly, then I'd expect them
to be pretty similar.
-> richard
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: equinox/felix behaviour with lib/endorsed
Posted by Guillaume Yziquel <gu...@crossing-tech.com>.
Hi.
Le Thursday 19 Apr 2012 à 09:07:47 (-0400), Richard S. Hall a écrit :
> Is your bundle importing the package in question? If not, you should
> import it in your bundle and then modify the system bundle to export
> the package.
>
> If you don't want to import it (which is a bad idea), you could also
> add that package to the framework's boot delegation property.
>
> The first option is the best.
>
> -> richard
I tried the second option first. Didn't work out.
I then tried the first option. I guess my problem is getting the system
bundle to export the package properly, which is not the case as I can
see from the karaf console.
However, it seems that there is some mechanism in karaf about the two
different config.properties and custom.properties to override one with
the other. The exact mechanism is still unclear to me. But this maybe
becomes a karaf question.
As to equinox / felix comparison, is there some detailed explanation as
to what the 'boot-time' differences precisely are? It seems many people
get into this mismatch at one point or another.
--
Guillaume Yziquel
Crossing-Tech
Parc Scientifique EPFL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: equinox/felix behaviour with lib/endorsed
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Is your bundle importing the package in question? If not, you should
import it in your bundle and then modify the system bundle to export the
package.
If you don't want to import it (which is a bad idea), you could also add
that package to the framework's boot delegation property.
The first option is the best.
-> richard
On 4/19/12 03:54 , Guillaume Yziquel wrote:
> Hi.
>
> I've encountered a problem concerning different behaviours between
> equinox and felix concerning jars in lib/endorsed (I'm using Karaf).
>
> I've got a bundle A that depends on classes located in a .jar in
> lib/endorsed. With equinox, the bundle A has no problems finding the
> classes. With felix, these classes are not found.
>
> Typical error messages I've found are:
>
> 09:50:39,041 | ERROR | rint Extender: 1 | BlueprintContainerImpl | ? ? | 10 - org.apache.aries.blueprint - 0.3.1 | Unable to start blueprint container for bundle my.bundle.A
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to instantiate components
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:644)[10:org.apache.aries.blueprint:0.3.1]
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:331)[10:org.apache.aries.blueprint:0.3.1]
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:227)[10:org.apache.aries.blueprint:0.3.1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_30]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_30]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_30]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_30]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_30]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_30]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_30]
> at java.lang.Thread.run(Thread.java:662)[:1.6.0_30]
> Caused by: java.lang.NoClassDefFoundError: my/missing/Class
> at java.lang.Class.getDeclaredConstructors0(Native Method)[:1.6.0_30]
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)[:1.6.0_30]
> at java.lang.Class.getConstructors(Class.java:1459)[:1.6.0_30]
> at org.apache.aries.blueprint.container.BeanRecipe.findMatchingConstructors(BeanRecipe.java:439)[10:org.apache.aries.blueprint:0.3.1]
> at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:263)[10:org.apache.aries.blueprint:0.3.1]
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:706)[10:org.apache.aries.blueprint:0.3.1]
> at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)[10:org.apache.aries.blueprint:0.3.1]
> at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219)[10:org.apache.aries.blueprint:0.3.1]
> at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:147)[10:org.apache.aries.blueprint:0.3.1]
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:640)[10:org.apache.aries.blueprint:0.3.1]
> ... 10 more
> Caused by: java.lang.ClassNotFoundException: my.missing.Class not found by my.bundle.A [233]
> at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:845)
> at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:74)
> at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1839)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_30]
> ... 20 more
>
> I'd be interested in understanding more in details why behaviours
> between felix and equinox are different on this point. Pointers to
> documentation would be welcome.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org