>> If you buffer you always have temporal inconsistency, no matter what. > That I do not understand? > I don't see what is hard to understand. The log record arrives at the > appender long after it was reported. Which you may not care too much about. > But sometimes it's a pain in the backside. But there is no guarantee when it arrives in the appender anyway? And as long as it is properly serialized what would the problem be?
>> The solution I like is DON'T buffer.
> Then you have ordering problems.
> There's no ordering issue when logging is setup with the framework.
Nope, because you took care of it. It is still there lurking to bite you though
:-)
> 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 special. We all know that and there's no use pretending,
> otherwise, we WOULD have solved this long ago.
Yes, and I am special too ... :-) And so is every developer's bundle I've seen
in my life ...
>> 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.
> There's nothing in the immediate model that prevents from debugging all day
> without restarts, that's just hyperbole. Logback supports configuration file
> updates (if you like), so you can tweak and flex those loggers/appenders any
> way you like at runtime (if you like).
Yes, of course you can, don't expect anything else. But each of those actions
requires _completely_ different handling than the unified OSGi solution to
those problems ...
Don't get me wrong, I understand that you have to live in the existing mess of
Java and life is tough there. I probably would do the same in your shoes.
However, I think it would be a pity that out of pragmatism we forget that an
insane amount of problems are caused by our strenuous desire for backward
compatibility.
Kind regards,
Peter Kriens
>
> Sincerely,
> - Ray
>
>
> 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>
>
>
>
> --
> 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)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
