[
https://issues.apache.org/jira/browse/FELIX-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239158#comment-14239158
]
Valentin Valchev commented on FELIX-4720:
-----------------------------------------
LogReaderService provides two ways of using it. Either by adding a log listener
(which according to your paper of OSGi Whiteboard pattern is wrong) or by using
LogReaderService.getLog().
I don't see the second option deprecated so why we shouldn't use it?
And ..
a) who says, that the log service must be implemented by the framework. Its
equinox choice. In all other projects it is implemented as a bundle.
b) we are aware that we can loose events. But I trust the system integrator to
configure the log service how many events should go in the log queue. I cannot
imagine that any system integrator will be happy to configure every bundle that
creates it's own log queue. If you go to a grocery shop you will be very
irritated to pay each item to a different cashier don't you? So would be the
integrator if he needs to configure 2 or 3 additional log queues. Probably all
implementations can set the size of the log queue to be 0 and webconsole/gogo
will show no logs. But if that is what the administrator of the system wants
who am I to argue?
c) again - it's equnox problem. The OSGi specifications doesn't say 'don't use
it'
d) OSGi services are also vendor-independence. You can choose which particular
implementation to use. If equinox is trouble - there are many other
implementations - pax logging, logback, felix log service, knopflerfish log
service, prosyst log service...
Web Console is also perfectly valid OSGi application, that relies on the
standard.
> Web Console and Gogo rely on Log history buffer in the Log Service
> ------------------------------------------------------------------
>
> Key: FELIX-4720
> URL: https://issues.apache.org/jira/browse/FELIX-4720
> Project: Felix
> Issue Type: Bug
> Components: Gogo Command, Web Console
> Reporter: Peter Kriens
>
> The OSGi Log Reader Service has a command to get the history of the log.
> However, the specification states that this history can be empty. The Equinox
> framework is nowadays registering a Log Reader Service that has such an empty
> history to prevent pinning objects in memory.
> Using the history this way was always at odds with the specification since
> the history was only intended to hold the start up events. The primary model
> of the Log Service is a dispatcher.
> I suggest that the Gogo log command and the Web Console maintain their own
> history buffer to become independent on this fragile history buffer in the
> Log Reader service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
