new Event API for message field get/set

[colinsurprenant]

this follows up on the idea in #4293

Just like we have getter and setter for timestamp, Event#timestamp and Event#timestamp= I believe we should add the same for message and add Event#message and Event#message=.

The message field is central to the Event and having these would avoid using clumsy fieldrefs like event["message"] or event["[message]"] in the plugins implementations.

[jordansissel]

message is only usually present in some but not all codecs. Plain and line codecs have it, but json and json_lines do not necessarily have it, nor does edn or msgpack.

[jordansissel]

To put it another way, there's no requirement for a message field. Some study of the ecosystem before Logstash 1.2 had me conclude that events are a tuple of (time, { data }) making timestamp the only realy required field.

That said, what makes us need a message setter/getter?

[colinsurprenant]

we don't per-se, but many plugins are using event["message"] since @message is a pretty standard field I figured we could promote it to have its own getter + setter. my idea is to try to avoid using field refs in the plugins code as much as possible when its not needed.

[jordansissel]

Maybe I'm reading too much into it, but technically @message was was removed as a field in Logstash 1.2.0.

In terms of providing getter+setters, maybe it's worth seeing what all the plugins use for their hard-coded field references, and if so, maybe provide a way to explicitly cache the field ref get/set call. or something?A kind of way that a plugin could precompute a fieldref call and invoke that directly instead of having the field ref string parsed every time? As an alternate hack on this, if the string is hard-coded, we could use the object id to cache the fieldref and instead of parsing the fieldref every time, just see if the object id is in the cache and use that result? (thinking outloud here)

[colinsurprenant]

err, I meant "message" and not "@messsage" ... correcting above.
Yes, the "special" field ref caching optimization is something I actually added for @timestamp see

logstash/logstash-core-event-java/src/main/java/com/logstash/PathCache.java

Lines 18 to 19 in 6a3e021

	this.timestamp = cache(TIMESTAMP);
	cache(BRACKETS_TIMESTAMP, this.timestamp);

and

logstash/logstash-core-event-java/src/main/java/com/logstash/ext/JrubyEventExtLibrary.java

Lines 113 to 118 in 6a3e021

	if (PathCache.getInstance().isTimestamp(r)) {
	if (!(value instanceof JrubyTimestampExtLibrary.RubyTimestamp)) {
	throw context.runtime.newTypeError("wrong argument type " + value.getMetaClass() + " (expected LogStash::Timestamp)");
	}
	this.event.setTimestamp(((JrubyTimestampExtLibrary.RubyTimestamp)value).getTimestamp());
	} else {

and we can extend that to other fields.

But I see your point for the fact that "message" is not a mendatory field, like @timestamp is. I will think about it a bit more and re-survey plugins to re-asses.

[colinsurprenant]

closing this, followup in #5234