[
https://issues.apache.org/jira/browse/FELIX-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239551#comment-14239551
]
Valentin Valchev commented on FELIX-4720:
-----------------------------------------
Imagine that you go to the grocery store. Then you have to pay:
- the tomatoes on cashier #1
- cucumbers on cashier #2
- all fruits on cashier #3
Would you visit that grocery store twice?
That's the same with the log storage. If I'm system integrator and had to
configure
- log queue of the log service
- log queue of the web console
- log queue of the gogo shell
he/she will be you, in the grocery store. Not use it again!
If I'm developer and create a queue
- i could be blamed if the queue is not configurable
- i could be blamed if there are bugs in the queue
- i could be blamed if it keeps some references to other bundles (through stack
trace elements of the exceptions)
But I have a *standard*, that says - there is a log queue. You bet, I'll use
it, instead of duplicating it.
Carsten, you said, that we can create a common queue, that is independent of
log reader. So, if not using equinox implementation, you will buffer the
entries twice and use more memory than needed?
And what about code reuse? - one the best features of OSGi is that you can
share the code, and use import-export, instead of copy-paste.
What about reliability and compliance? Can I trust the OSGi standard if we need
to change applications, because some vendor doesn't implement it fully?
P.S: I'm posting some parts of org.osgi.service.log.LogEntry javadoc;
{code}
/**
* Returns the exception object associated with this {@code LogEntry}
* object.
*
* <p>
* In some implementations, the returned exception may not be the
original
* exception. To avoid references to a bundle defined exception class,
thus
* preventing an uninstalled bundle from being garbage collected, the
Log
* Service may return an exception object of an implementation defined
* Throwable subclass. The returned object will attempt to provide as
much
* information as possible from the original exception object such as
the
* message and stack trace.
{code}
So, there *is* a way, to prevent pinning objects in memory when implementing
the log reader service. Is equinox, that decided not to implement it that way
and instead to return empty list of log entries. Although that the above
solution is simple, I agree, that it's slower and requires more temporary
memory. So it's inefficient. But if we want to correctly implement web console
log plugin, gogo shell log command, that inefficient code is multiplied by 2.
Or by 5, or 6 - depending how many applications do you have to browse the log
entries. And yet, if could be only 1 place - the LogReaderService.
> 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)
