[
https://issues.apache.org/jira/browse/FELIX-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240842#comment-14240842
]
Valentin Valchev commented on FELIX-4720:
-----------------------------------------
The problem here is not only if we should do it or not. There are two much more
significant problems:
1. As a consultant, when I go to a client and want to convince them that OSGi
is great, one of the key benefits I point to is that it is standard, and they
have the freedom to choose whatever implementation they want and it still will
work in compatible way. OSGi has a TCK that verifies the implementations and
certifies them for compatibility.
2. The other thing is *usability*. As a developer I can just implement own log
queue and it will go great. But as product manager I should also care of *how
clients feel it* - and it should be *easy and intuitive*. If they had to
configure 2+ log queues, that's not acceptable for them, then also not for me.
> 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)
