You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Don Brown <do...@gmail.com> on 2008/10/16 01:26:36 UTC
OSGi class overrides?
We got the puzzling exception:
Caused by: java.lang.NoClassDefFoundError: org.osgi.vendor.framework
property not set
at org.osgi.framework.FrameworkUtil$ImplHolder.run(FrameworkUtil.java:69)
in one of our integration builds for Resin, but not on any of the
other app servers. Turns out the Felix framework jar "overrides"
several OSGi classes from the osgi core jar, and apparently, Resin
loads the classes differently then other app servers.
I'm a bit puzzled as to why this design would even work in the first
place. How could you ensure that app servers would load the felix
overrides before the osgi core classes? Shouldn't the osgi core jar,
instead, be folded into the framework jar so there are no such
uncertainties?
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGi class overrides?
Posted by Don Brown <do...@gmail.com>.
Sure, my comments on the design was under the false assumption that
the osgi-core and felix jars were both deployed to WEB-INF/lib, having
not understood the main jar build process. Once I do a vendor fork of
the main jar to include the vendor fork of the framework jar, my issue
should be resolved.
Don
On Thu, Oct 16, 2008 at 8:13 PM, Peter Kriens <pe...@aqute.biz> wrote:
> The OSGi -explicitly- allows framework vendors to re-implement some of the
> classes in the osgi jars. The reason is that they can provide more
> performant hooks because they can use framework specific classes while the
> spec has to remain generic.
>
> Kind regards,
>
> Peter Kriens
>
>
> On 16 okt 2008, at 01:26, Don Brown wrote:
>
>> We got the puzzling exception:
>>
>> Caused by: java.lang.NoClassDefFoundError: org.osgi.vendor.framework
>> property not set
>> at
>> org.osgi.framework.FrameworkUtil$ImplHolder.run(FrameworkUtil.java:69)
>>
>> in one of our integration builds for Resin, but not on any of the
>> other app servers. Turns out the Felix framework jar "overrides"
>> several OSGi classes from the osgi core jar, and apparently, Resin
>> loads the classes differently then other app servers.
>>
>> I'm a bit puzzled as to why this design would even work in the first
>> place. How could you ensure that app servers would load the felix
>> overrides before the osgi core classes? Shouldn't the osgi core jar,
>> instead, be folded into the framework jar so there are no such
>> uncertainties?
>>
>> Don
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGi class overrides?
Posted by Peter Kriens <pe...@aqute.biz>.
The OSGi -explicitly- allows framework vendors to re-implement some of
the classes in the osgi jars. The reason is that they can provide more
performant hooks because they can use framework specific classes while
the spec has to remain generic.
Kind regards,
Peter Kriens
On 16 okt 2008, at 01:26, Don Brown wrote:
> We got the puzzling exception:
>
> Caused by: java.lang.NoClassDefFoundError: org.osgi.vendor.framework
> property not set
> at org.osgi.framework.FrameworkUtil
> $ImplHolder.run(FrameworkUtil.java:69)
>
> in one of our integration builds for Resin, but not on any of the
> other app servers. Turns out the Felix framework jar "overrides"
> several OSGi classes from the osgi core jar, and apparently, Resin
> loads the classes differently then other app servers.
>
> I'm a bit puzzled as to why this design would even work in the first
> place. How could you ensure that app servers would load the felix
> overrides before the osgi core classes? Shouldn't the osgi core jar,
> instead, be folded into the framework jar so there are no such
> uncertainties?
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGi class overrides?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Don,
Framework folds in the OSGi classes it needs...main actually folds in
framework.
The difference between the two is that the main pom.xml has exclusions
for the dependencies of framework (i.e., OSGi core and compendium), so
that they are not included on the class path when using main.
If you are using Maven, it seems like you should be able to do the same
thing on your dependency on framework.
-> richard
Don Brown wrote:
> Ok, I think I'm closer to the problem. We had to do a vendor branch
> of the framework jar, due to several Felix issues that have been fixed
> on trunk, but not released. When depending on the framework jar in
> Maven, it brings down the osgi core jar as well. Since we weren't
> using the Main class, we switched our dependency to just the framework
> jar. Unfortunately, it looks like in your main pom.xml, you collapse
> the osgi core and framework jar into one jar, but since we are
> depending on just the framework, we get the separate osgi core jar as
> well.
>
> I guess the solution for us will be to do a vendor branch of main as
> well, so that we get the updated framework and the collapsed
> dependencies. It seems to be a lot of work just to get a couple
> fixes, but I guess that's the only option.
>
> Don
>
> On Thu, Oct 16, 2008 at 1:13 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>
>> Don,
>>
>> I think there is some confusion. The framework, and subsequently main, do
>> embed the needed OSGi core and compendium classes. The only thing you need
>> to run Felix, is felix.jar (which is actually
>> org.apache.felix.main-1.x.x.jar).
>>
>> Maybe you have the OSGi classes on your class path twice?
>>
>> -> richard
>>
>> Don Brown wrote:
>>
>>> We got the puzzling exception:
>>>
>>> Caused by: java.lang.NoClassDefFoundError: org.osgi.vendor.framework
>>> property not set
>>> at
>>> org.osgi.framework.FrameworkUtil$ImplHolder.run(FrameworkUtil.java:69)
>>>
>>> in one of our integration builds for Resin, but not on any of the
>>> other app servers. Turns out the Felix framework jar "overrides"
>>> several OSGi classes from the osgi core jar, and apparently, Resin
>>> loads the classes differently then other app servers.
>>>
>>> I'm a bit puzzled as to why this design would even work in the first
>>> place. How could you ensure that app servers would load the felix
>>> overrides before the osgi core classes? Shouldn't the osgi core jar,
>>> instead, be folded into the framework jar so there are no such
>>> uncertainties?
>>>
>>> Don
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGi class overrides?
Posted by Don Brown <do...@gmail.com>.
Ok, I think I'm closer to the problem. We had to do a vendor branch
of the framework jar, due to several Felix issues that have been fixed
on trunk, but not released. When depending on the framework jar in
Maven, it brings down the osgi core jar as well. Since we weren't
using the Main class, we switched our dependency to just the framework
jar. Unfortunately, it looks like in your main pom.xml, you collapse
the osgi core and framework jar into one jar, but since we are
depending on just the framework, we get the separate osgi core jar as
well.
I guess the solution for us will be to do a vendor branch of main as
well, so that we get the updated framework and the collapsed
dependencies. It seems to be a lot of work just to get a couple
fixes, but I guess that's the only option.
Don
On Thu, Oct 16, 2008 at 1:13 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> Don,
>
> I think there is some confusion. The framework, and subsequently main, do
> embed the needed OSGi core and compendium classes. The only thing you need
> to run Felix, is felix.jar (which is actually
> org.apache.felix.main-1.x.x.jar).
>
> Maybe you have the OSGi classes on your class path twice?
>
> -> richard
>
> Don Brown wrote:
>>
>> We got the puzzling exception:
>>
>> Caused by: java.lang.NoClassDefFoundError: org.osgi.vendor.framework
>> property not set
>> at
>> org.osgi.framework.FrameworkUtil$ImplHolder.run(FrameworkUtil.java:69)
>>
>> in one of our integration builds for Resin, but not on any of the
>> other app servers. Turns out the Felix framework jar "overrides"
>> several OSGi classes from the osgi core jar, and apparently, Resin
>> loads the classes differently then other app servers.
>>
>> I'm a bit puzzled as to why this design would even work in the first
>> place. How could you ensure that app servers would load the felix
>> overrides before the osgi core classes? Shouldn't the osgi core jar,
>> instead, be folded into the framework jar so there are no such
>> uncertainties?
>>
>> Don
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGi class overrides?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Don,
I think there is some confusion. The framework, and subsequently main,
do embed the needed OSGi core and compendium classes. The only thing you
need to run Felix, is felix.jar (which is actually
org.apache.felix.main-1.x.x.jar).
Maybe you have the OSGi classes on your class path twice?
-> richard
Don Brown wrote:
> We got the puzzling exception:
>
> Caused by: java.lang.NoClassDefFoundError: org.osgi.vendor.framework
> property not set
> at org.osgi.framework.FrameworkUtil$ImplHolder.run(FrameworkUtil.java:69)
>
> in one of our integration builds for Resin, but not on any of the
> other app servers. Turns out the Felix framework jar "overrides"
> several OSGi classes from the osgi core jar, and apparently, Resin
> loads the classes differently then other app servers.
>
> I'm a bit puzzled as to why this design would even work in the first
> place. How could you ensure that app servers would load the felix
> overrides before the osgi core classes? Shouldn't the osgi core jar,
> instead, be folded into the framework jar so there are no such
> uncertainties?
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org