logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: I think I may have introduced an OSGi race condition.
Date Mon, 21 Jul 2014 14:28:23 GMT
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>

Mime
View raw message