feature-#34 parallel logging #42
Conversation
…nder implementations
kortemik
changed the title
src/main/java/com/teragrep/jla_01/syslog/hostname/Hostname.java
Outdated
Show resolved
Hide resolved
src/main/java/com/teragrep/jla_01/syslog/hostname/Hostname.java
Outdated
Show resolved
Hide resolved
|
|
||
| import com.teragrep.rlp_01.pool.Stubable; | ||
|
|
||
| public interface RelpAppender<E> extends Stubable { |
There was a problem hiding this comment.
the naming is to reflect the UnsynchronizedAppenderBase naming
| * Unsynchronized version of RELP Appender for Logback. It is configured in a Bean manner using setters by Logback. | ||
| * @param <E> | ||
| */ | ||
| public final class RlpLogbackAppender<E> extends UnsynchronizedAppenderBase<E> implements IRelpAppenderConfig<E> { |
There was a problem hiding this comment.
As far as I know, Bean type classes unfortunately can't be immutable due to the way they are configured via the setters and reflection.
| import com.teragrep.rlo_14.SyslogMessage; | ||
|
|
||
| public interface SyslogRecord { | ||
| SyslogMessage getRecord(); |
There was a problem hiding this comment.
Yes it could be. I will just leave it as it is for now because #44 should change it
| SyslogRecord syslogRecord = new SyslogRecordConfigured(hostname, appName); | ||
| syslogRecord = new SyslogRecordTimestamp(syslogRecord); | ||
| syslogRecord = new SyslogRecordOrigin(syslogRecord, originalHostname); | ||
| if (enableEventId48577) { |
There was a problem hiding this comment.
enableEventId48577 boolean seems to configure the behaviour of this method here, so there seems to be use cases where sometimes you want the eventId, sometimes you don't.
Should this be separated into a different object, so that you have RelpAppenders that include the eventId and RelpAppenders that don't include it, to make it more obvious when the eventId will be appended, and when it's omitted?
There was a problem hiding this comment.
please create an issue about this
| eventIdSDE.addSDParam("uuid", uuid); | ||
| eventIdSDE.addSDParam("source", "source"); | ||
|
|
||
| long unixtime = System.currentTimeMillis(); |
There was a problem hiding this comment.
In SyslogRecordTimeStamp the timestamps are generated using the Instant object, and here we use another method for the same end result. Not sure if it matters, but should we use Instant here as well to be consistent with other objects on what method we use to measure time?
There was a problem hiding this comment.
very good point. please create an issue about this!
No description provided.