Provide pipeline-based message decorator #41
Conversation
dennisoelkers
force-pushed
the
provide-message-decorator
branch
from
10f2b56
to
63430c1
Compare
|
We could implement a InterpreterListener to make Graylog2/graylog2-server#2408 (comment) easier |
|
Good idea. I am wondering how we pipe back the information to the consumer (the web interface) without leaking implementation details. I will check the details how the field list is constructed to find that out. |
|
AFAICS the field list comes directly out of the |
| new NoopInterpreterListener()); | ||
| final ResultMessage outMessage = ResultMessage.fromMessage(message, inMessage.getIndex(), inMessage.getHighlightRanges()); | ||
|
|
||
| results.add(outMessage); |
There was a problem hiding this comment.
Here we also need to check for Message#getFilteredOut before adding it to the new result set in case the rule dropped this message.
There was a problem hiding this comment.
Alternatively we could use an interpreter listener and merely hide the filtered messages in the UI.
This gets trickier by the minute :)
There was a problem hiding this comment.
So they are not actually removed from the list but flagged instead?
There was a problem hiding this comment.
Yes, that would be an option.
Right now all the statistics about the result set are off, of course, when messages are simply removed.
I guess this is a kind of a special case, the common one would be to somehow mutate messages to include new or changed field content, and not dropping entire messages.
However, for the use case to filter messages based on security rules for example, this could still be useful.
We probably need to come up with a better description though.
You mean something like this? :) I removed that again, because it seemed a bit overkill to me, but I think it makes sense in a few more ways (like providing information to the UI which fields were changed/added/deleted/what their former content was etc., so it is transparent/switchable in the ui), but I kept this out of the first implementation to prevent it getting too complex and evolve it instead. |
dennisoelkers
force-pushed
the
provide-message-decorator
branch
from
63430c1
to
5203214
Compare
|
Yeah, I think we need to unify the decorators to make the UI more usable. For the alpha I could live with leaving it like it is implemented now, but for a final I would vote for changing it. |
dennisoelkers
force-pushed
the
provide-message-decorator
branch
from
5203214
to
7213b08
Compare
| return new MessageCollection(fullyProcessed); | ||
| } | ||
|
|
||
| public List<Message> processForPipelines(Message message, String msgId, Set<String> pipelines, InterpreterListener interpreterListener) { |
There was a problem hiding this comment.
I'd like to refactor this in a future change, because the semantics of this refactored call are a little surprising:
- the message parameter is mutated and needs to be reused by the caller
- the return value are only newly created messages and do not contain the original message
While this makes sense in the original call site for other users it's quite surprising. Technically everything's correct, though.
There was a problem hiding this comment.
Hm, yeah. I am a bit surprised now that I did this way too. I am checking why and if it's possible to change for this PR already, because I don't like it at all.
There was a problem hiding this comment.
I think this is simply because of the structure of the original implementation.
As we need to revisit the interpreter anyway (and we know it's not ideal in performance) I'd leave it as it is for now.
|
lgtm, the other changes we'll do incrementally in more PRs 👍 |
This is still WIP but already open for remarks.