I've actually got a work around for this. Just need to refresh the API bundle on activation of the Core bundle. Simple.
On 20 July 2014 23:50, Matt Sicker <[email protected]> wrote: > Right, it's only in specific scenarios right now like swapping in bundles > without refreshing them. > > > On 20 July 2014 23:26, Remko Popma <[email protected]> wrote: > >> Why do you say an OSGi race condition? Does this only happen when running >> in an OSGi container? >> >> >> On Mon, Jul 21, 2014 at 12:54 PM, Matt Sicker <[email protected]> wrote: >> >>> I'm not sure on how to reproduce it, but sometimes LogManager gets a >>> Log4jContextFactory, sometimes it gets a SimpleLoggerContextFactory. Both >>> bundle listeners are synchronous, but I think the order that >>> SynchronousBundleListener classes get invoked is undefined. It appears that >>> coordinating two separate bundles in such a way is harder than I expected. >>> >>> In SLF4J, it's a bit simpler since the API doesn't include a default >>> implementation. In that case, the API bundle can wait until an >>> implementation bundle is available before itself becoming available. >>> >>> Any ideas on how to do more appropriate locking or allowing this to work >>> out of order? I'd prefer to avoid adding in the OSGi compendium services >>> (although they would certainly make this easier) in order to prevent >>> unnecessary dependencies in OSGi. >>> >>> -- >>> Matt Sicker <[email protected]> >>> >> >> > > > -- > Matt Sicker <[email protected]> > -- Matt Sicker <[email protected]>
