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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
