> On 27 Aug 2018, at 22:40, Raymond Auge via osgi-dev <osgi-dev@mail.osgi.org> > wrote: > On Mon, Aug 27, 2018 at 4:19 PM, David Leangen via osgi-dev > <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote: > Hi Peter and Ray, > Thank you very much for the suggestions! > I’ll take a look at the code. It is my hope that I don’t need to pull in any > additional dependencies. Maybe I’ll get some hints in the code as to how not > to lose any logs. > If I am reading the Felix Logback page correctly, It’s a bit odd that the > OSGi log service, when started up normally, misses some information during > startup. In my mind, that seems like a problem with the spec. > It's not a problem with the spec. The problem is with the buffering which the > spec cannot avoid. > You can't accurately predict how much buffer is needed > If you buffer to much you _may_ have memory issues Yes, but if you limit the buffering to the framework start and the log service up and running you can make a reasonable guess how long the buffer is. Only when out of the ordinary stuff happens you need a large buffer. However, than almost invariably the early records contain sufficient information to diagnose wtf happened. Second, once the log service is up and running the buffer can be flushed.
> If you buffer to little you _may_ lose records
> If you buffer you always have temporal inconsistency, no matter what.
That I do not understand?
> The solution I like is DON'T buffer.
Then you have ordering problems.
> The only way NOT to buffer is make sure the log service starts with an
> appender immediately. That's what the "immediate" logging approach provides.
> It puts the log service setup and configuration immediately at the framework
> level so that no buffering is used or required.
That is a good solution but it makes logging extremely 'special'. Agree this is
a very foundational service but losing the possibility to have appenders in
bundles is a pretty big thing.
> Logging is an infrastructure detail unlike any other. It really must be
> bootstrapped with the runtime as early as possible. It's not ideal to handle
> it at the module layer, so I propose not to (thought it still integrates
> nicely with any bundle based logging APIs as demonstrated in the Felix
> logback integration tests).
The problem with this approach is that it is also true for configuration admin,
and DS, and event admin, etc. etc. They are all infrastructure and they all
have ordering issues. Going down your route is imho a slippery slope. Before
you know you're back to a completely static model. And maybe that is not bad, I
just prefer a solution where I can debug all day on the same framework that is
never restarted. I also dislike hybrids since they tend to become quite complex
to handle on other levels.
Kind regards,
Peter Kriens
>
> Sincerely,
> - Ray
>
>
> This issue, the problem of startup dependencies and configuration… Maybe
> there is something missing in the spec in terms of some kind of "boot
> service” that would handle these “common” problems. If the problems are so
> common, then maybe it is a sign of a gap in the specs… Just a thought.
>
>
> Anyway, thanks!
> =David
>
>
>
>> On Aug 27, 2018, at 22:19, Raymond Auge <raymond.a...@liferay.com
>> <mailto:raymond.a...@liferay.com>> wrote:
>>
>> There's setup details in the integration tests [1]
>>
>> HTH
>> - Ray
>>
>> [1] https://github.com/apache/felix/tree/trunk/logback/itests
>> <https://github.com/apache/felix/tree/trunk/logback/itests>
>>
>> On Mon, Aug 27, 2018 at 9:15 AM, Raymond Auge <raymond.a...@liferay.com
>> <mailto:raymond.a...@liferay.com>> wrote:
>> My personal favourite is the Apache Felix Logback [1] integration which
>> supports immediate logging when follow the correct steps. I feel it's the
>> best logging solution available.
>>
>> There are a couple of prerequisites as outlined in the documentation. But
>> it's very simple to achieve your goal (NO BUFFERING OR MISSED LOG RECORDS)!
>>
>> [1]
>> http://felix.apache.org/documentation/subprojects/apache-felix-logback.html
>> <http://felix.apache.org/documentation/subprojects/apache-felix-logback.html>
>>
>> - Ray
>>
>> On Mon, Aug 27, 2018 at 7:50 AM, BJ Hargrave via osgi-dev
>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote:
>> Equinox has the LogService implementation built into the framework, so it
>> starts logging very early.
>>
>> In the alternate, for framework related information, you can write your own
>> launcher and it can add listeners for the framework event types.
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
>> hargr...@us.ibm.com <mailto:hargr...@us.ibm.com>
>>
>>
>> ----- Original message -----
>> From: David Leangen via osgi-dev <osgi-dev@mail.osgi.org
>> <mailto:osgi-dev@mail.osgi.org>>
>> Sent by: osgi-dev-boun...@mail.osgi.org
>> <mailto:osgi-dev-boun...@mail.osgi.org>
>> To: osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> Cc:
>> Subject: [osgi-dev] Logger at startup
>> Date: Sun, Aug 26, 2018 3:06 PM
>>
>> Hi!
>>
>> I’m sure that this question has been asked before, but I did not
>> successfully find an answer anywhere. It applies to both R6 and R7 logging.
>>
>> I would like to set up diagnostics so I can figure out what is happening
>> during system startup. however, by the time the logger starts, I have
>> already missed most of the messages that I needed to receive and there is no
>> record of the things I want to see. Another oddity is that even after the
>> logger has started, some messages are not getting logged. I can only assume
>> that there is some concurrency/dynamics issue at play.
>>
>> In any case, other than using start levels, is there a way of ensuring that
>> the LogService (or Logger) is available when I need it?
>>
>>
>> Thanks!
>> =David
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>
>>
>>
>> --
>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>>
>>
>>
>> --
>> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
>
>
> --
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance)
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
