small change to allow pekko-actor-testkit-typed to work with slf4j-api v2

[pjfanning]

Pekko main branch (future pekko 1.1.0 dev line) already uses slf4j-api v2 and we had to react to a breaking change with the slf4j LoggingEvent getMarker method being replaced with a getMarkers method - see #748

Since testkit is only used in testing, I think we can live with a solution that ignores the Marker on LoggingEvent if the getMarker method is missing.

TestAppender change in #748 is not needed because the ILoggingEvent class still has a getMarker method (just deprecated).
https://logback.qos.ch/apidocs/ch/qos/logback/classic/spi/ILoggingEvent.html

[aaparent]

Let me pull the repo and try those changes

[aaparent]

Sorry to came back that late.
I pulled all the repos I needed (incubator-pekko, incubator-pekko-connectors and incubator-pekko-connectors-kafka) and published locally using a specific version, else I would get errors about using incompatible versions.

Everything is running fine with your changes, thanks a lot!

[pjfanning]

@aaparent in theory, you only need to rebuild the actor-typed-testkit jar. Would you be able to share a test case? I haven't found an existing test that breaks when slf4j V2 is used.

[aaparent]

I think that was due to the way I built the jar (simple publishLocal - not setting a version or whatsoever).
It was complaining about the versions not matching and being possibly incompatible.

It was triggered by : https://github.com/apache/incubator-pekko/blob/main/actor/src/main/scala/org/apache/pekko/util/ManifestInfo.scala#L177

That's why I built all I needed instead of just one jar (setting a version this time).

[mdedetrich]

Overall I like the direction of the PR but would it be possible to use reflection to get evt.getMarkers if it happens to point to the same type as evt.getMarker (just contained within a list) rather than just doing None?

That way we could get the best of both worlds.

Now that I think of it, honestly think that we likely should have bumped to slf4j 2 in Pekko 2.0.x series since this is strictly breaking but this may be good enough. Hence I think this calls for a discussion on the Pekko mailing list about whether we should bump libraries that have breaking changes in Pekko minor version bumps

[mdedetrich]

Nice, lgtm