search

vy / log4j2-logstash-layout

Log4j 2.x plugin for customizable and Logstash-friendly JSON layout.
Apache License 2.0
89 stars 26 forks source link

Add support for Custom Serializers #38

Closed J0nathan-S closed 5 years ago

J0nathan-S commented 5 years ago

It would be nice, if there was support for custom serializers in order to be able to for example use org.json instead of fasterxml.

vy commented 5 years ago

Would you mind elaborating on a bit on your use case, please? If you are concerned about JAR Hell, log4j2-logstash-layout-fatjar is supposed to address that issue.

J0nathan-S commented 5 years ago

No, it‘s not about Jar Hell. I am logging a message into elasticsearch. Logstash-layout formats the json object which is set in the logmessage. Unfortunately it keeps throwing an exception, which says that the Jackson parser was not able to find a serializer to parse the JSONObject into Json. It would be nice, if there was a way to replace that Jackson Serializer with one of another Library. I am using org.json in my project and I am trying to get rid of fasterxml, since I am using org.json for validation purposes anyways.

vy commented 5 years ago

No, it‘s not about Jar Hell. I am logging a message into elasticsearch. Logstash-layout formats the json object which is set in the logmessage. Unfortunately it keeps throwing an exception, which says that the Jackson parser was not able to find a serializer to parse the JSONObject into Json.

That is really strange. It might point us in the direction of a bug. Would you mind providing some more context (the full stack trace, involved software components, their versions, etc., and if possible, a setup where I can reproduce the error), please?

It would be nice, if there was a way to replace that Jackson Serializer with one of another Library. I am using org.json in my project and I am trying to get rid of fasterxml, since I am using org.json for validation purposes anyways.

It would indeed be nice, but abstracting away the existing JSON generation logic to enable the wiring of external JSON libraries is a significant piece of work. Further, we might not guarantee the space and runtime efficiency we can right now with Jackson. That is, the way we employ Jackson yields superior performance with close to zero garbage collection. Breaking this contract will defeat one of the major selling points of the project.

In summary, I am inclined to fix your problem rather than abstracting away the JSON generation in the plugin. My 2 cents...