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 <boards@gmail.com> 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 <remko.popma@gmail.com> 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 <boards@gmail.com> 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 <boards@gmail.com>




--
Matt Sicker <boards@gmail.com>



--
Matt Sicker <boards@gmail.com>