Skip to content
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

LogstashBasicMarker implementation is inefficient and out-off-sync with implementation provided by Slf4J #613

Closed
brenuart opened this issue Aug 19, 2021 · 6 comments · Fixed by #617 or #636
Milestone

Comments

@brenuart
Copy link
Collaborator

LogstashBasicMarker is a now obsolete copy of org.slf4j.helpers.BasicMarker at version 1.7.12
The original implementation has been updated and improved since then. The version included in logback-logstash-encoder should be updated accordingly.

A few points:

  • replace the use of Vector by a more efficient List implementation
  • use a StringBuilder instead of a StringBuffer

Note: Slf4J BasicMarker has a package protected constructor and cannot be easily re-used in other project - reason why the project maintains its own copy.

@brenuart
Copy link
Collaborator Author

brenuart commented Aug 20, 2021

Instead of copying an alternative is to declare LogstashBasicMarker in the org.slf4j.helpers package with a public constructor (inside this project) and extend from it.

@philsttr What do you think of this? Would it cause issues in OSGI environments?

@philsttr
Copy link
Collaborator

philsttr commented Aug 20, 2021

Instead of copying an alternative is to declare LogstashBasicMarker in the org.slf4j.helpers package with a public constructor (inside this project) and extend from it.

It was originally in org.slf4j.helpers, but was moved into net.logstash.logback.marker to fix #104 . I think it should stay in net.logstash.logback.marker

@brenuart
Copy link
Collaborator Author

I see. So better to leave it like this and keep an "internal" copy.

This class is public and behaves the same as the SLF4J version. Users may be tempted to use it as base class for their own specialisations... Is it something we want to support? Or should we protect it?
Personally, I would instead merge everything inside LogstashMarker and have only "one" base class for all of our markers.

Finally, we "copied" the class... but don't you think we should copy the relevant tests as well ?

brenuart added a commit that referenced this issue Aug 24, 2021
…#617)

* Use a CopyOnWriteArrayList instead of Vector and remove synchronisation (#616)
* Remove useless synchronisation on LogstashMarker (#616)
* Remove references from equals/hashCode and rely on the default behaviour (#613)

Closes #613, #616
@philsttr philsttr added this to the 7.0 milestone Aug 28, 2021
@philsttr
Copy link
Collaborator

Is it something we want to support?

No

Or should we protect it?

Yes, probably worth reducing the visibility.

but don't you think we should copy the relevant tests as well ?

definitely

@brenuart
Copy link
Collaborator Author

brenuart commented Sep 3, 2021

Yes, probably worth reducing the visibility.

@philsttr Or even better - collapse the two implementations into one and keep only the LogstashMarker...

@philsttr
Copy link
Collaborator

philsttr commented Sep 3, 2021

I kept them separate to easily see the differences between our copied version and the original... primarily so it would make it easier to sync.

However, if the logstash-logback-encoder implementation is going to start diverging more, then I don't see a reason to keep them separate.

@brenuart brenuart linked a pull request Sep 8, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants