Skip to content

Conversation

@jordanjennings
Copy link
Contributor

@jordanjennings jordanjennings commented Apr 3, 2025

Fixes #1060

Although this fixes the compatibility issue with logback 1.5.13, it does have breaking version compatibility changes (due to the underlying breaking change made by logback itself). I've updated the README to indicate new minimum versions, but I didn't change anything with the pom.xml version number, even though this might be worthy of a major version bump since it breaks backwards compatibility with logback versions.

@jordanjennings jordanjennings force-pushed the fix-logback-breaking-change branch from ea6b795 to 2c4e6b9 Compare April 3, 2025 14:20
@jordanjennings jordanjennings force-pushed the fix-logback-breaking-change branch from 2c4e6b9 to 126adcf Compare April 3, 2025 14:39
@philsttr
Copy link
Collaborator

philsttr commented Apr 3, 2025

Thanks @jordanjennings ! I really appreciate your investigation and fix.

I agree that this would require a major version bump in logstash-logback-encoder.

However, I am interested to see if there is a way to support both the old and new logback versions in 8.x. Even if it was "ugly", we could probably live with it until the next major logstash-logback-encoder version, at which point it could be removed.

@jordanjennings
Copy link
Contributor Author

jordanjennings commented Apr 4, 2025

@philsttr Yes, there is a way using reflection, but it's a bit ugly. Here's how I originally approached the fix:

  @Override
  protected PatternLayoutBase<ILoggingEvent> createLayout() {
    PatternLayoutBase<ILoggingEvent> layout = new PatternLayout();

    try {
      Field field = PatternLayoutBase.class.getDeclaredField("instanceConverterMap");
      ParameterizedType type = (ParameterizedType) field.getGenericType();
      Type valueType = type.getActualTypeArguments()[1];

      if (valueType.getTypeName().equals("java.lang.String")) {
        putPropertyUnchecked(layout.getInstanceConverterMap(), EnhancedPropertyConverter.class.getName());
      } else if (valueType.getTypeName().equals("java.util.function.Supplier<ch.qos.logback.core.pattern.DynamicConverter>")) {
        putPropertyUnchecked(layout.getInstanceConverterMap(), EnhancedPropertyConverter::new);
      } else {
        throw new IncompatibleClassChangeError(
            "Unexpected type found for instanceConverterMap, logback-core dependency version is not compatible");
      }

    } catch (NoSuchFieldException e) {
      throw new IncompatibleClassChangeError(
          "Field instanceConverterMap not found, logback-core dependency version is not compatible");
    }
    return layout;
  }

  @SuppressWarnings({"rawtypes", "unchecked"})
  private void putPropertyUnchecked(Map map, String value) {
    map.put("property", value);
  }

  @SuppressWarnings({"unchecked", "rawtypes"})
  private void putPropertyUnchecked(Map map, Supplier<Object> value) {
    map.put("property", value);
  }

I didn't go with this approach because it felt very brittle and likely to break again. However, it does keep compatibility until a major release of logstash-logback-encoder can be done. What do you think about this approach?

@philsttr
Copy link
Collaborator

philsttr commented Apr 4, 2025

Hey @jordanjennings ,

Yeah, I agree it's a bit brittle, but this repo has had to do similar things in the past to maintain compatibility with various breaking changes in logback. So, this works for me. And it's easy to remove in the next major version of logstash-logback-encoder, so at least it's not permanent.

philsttr added a commit that referenced this pull request Apr 5, 2025
…1061)

Maintain PatternLayout compatibility with logback <= 1.5.12

In logback 1.5.13, PatternLayoutBase.getInstanceConverterMap changed from `Map<String, String>` to `Map<String, Supplier<DynamicConverter>`

To maintain compatibility with logback <= 1.5.12, use reflection to determine the type of the Map, and add entries appropriately.

Fixes #1060

Co-authored-by: Jordan Jennings <[email protected]>
@philsttr
Copy link
Collaborator

philsttr commented Apr 5, 2025

Hey @jordanjennings, I incorporated your approach and merged it in f4e5ff3

Thanks again for the contribution!

@philsttr philsttr closed this Apr 5, 2025
@jordanjennings
Copy link
Contributor Author

@philsttr that’s fantastic news, thank you! What’s the expected timeline for cutting a release?

@jordanjennings jordanjennings deleted the fix-logback-breaking-change branch April 5, 2025 16:48
@philsttr
Copy link
Collaborator

philsttr commented Apr 5, 2025

Working on it now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Breaking change in logback 1.5.13 breaks %property{key} patterns

2 participants