-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds middleware/serializers construction through Log4j configuration #196
base: main
Are you sure you want to change the base?
Conversation
This certainly seems like the way to do it .. and probably should have been like that from the beginning, i.e. since the concept of user configurable serializers was introduced in this project. Backwards compatibility Documentation |
Yes, that is the idea. The old unit test The new unit test |
Hi @ppkarwasz, Thanks. |
The current mechanism creates the middleware, eventBodySerializer and eventHeaderSerializer using the default constructor of their classes, without any configuration possibility. While maintaining backward compatibility, we allow to configure those components through Log4j plugin mechanism.
@bparmar-splunk: I rebased the contribution and rewrote it to use a builder instead of a 33 parameter constructor (which I deprecated). BTW: all |
If the
HttpSenderMiddleware
,EventBodySerializer
andEventHeaderSerializer
objects require additional configuration, instantiation by class name might not be enough (see this question on StackOverflow).While maintaining backward compatibility, this PR adds the possibility to configure additional components through Log4j:
The elements
SomeMiddleware
,SomeBodySerializer
andSomeHeaderSerializer
must be Log4j plugins of element typemiddleware
,eventBodySerializer
andeventHeaderSerializer
respectively.This PR contains a simple unit test.