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