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

Reimplement LogStash::String setting in Java #16576

Merged
merged 17 commits into from
Jan 24, 2025

Conversation

andsel
Copy link
Contributor

@andsel andsel commented Oct 17, 2024

Release notes

[rn:skip]

What does this PR do?

Reimplements LogStash::Setting::String Ruby setting class into the org.logstash.settings.StringSetting and exposes it through java_import as LogStash::Setting::StringSetting.
Updates the rspec tests in two ways:

  • logging mock is now converted to real Log4J appender that spy log line that are later verified
  • verifies java.lang.IllegalArgumentException instead of ArgumentError is thrown because the kind of exception thrown by Java code, during verification.

Why is it important/What is the impact to the user?

As a developer I want use Java classes to shape the configuration settings.

Checklist

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • [ ] I have made corresponding changes to the documentation
  • [ ] I have made corresponding change to the default configuration files (and/or docker env variables)
  • I have added tests that prove my fix is effective or that my feature works

Author's Checklist

  • Implements the other constructors, with 2 and 3 params and spread the use
    • Execute SPEC_OPTS="-fd -P logstash-core/spec/logstash/runner_spec.rb" ./gradlew --rerun-tasks :logstash-core:rubyTests there is a problem in reading the deprecation logger messages in
      expect(deprecation_logger_stub).to receive(:deprecated).with(a_string_including "`http.host` is a deprecated alias for `api.http.host`")
      . Suggestion mock the Appender and reconfigure logs?
  • Check the code for other instantiations of LogStash::String.new
  • Translate RSpec tests to JUnit if there are or cover with some testing
  • [ ] Rename StringSetting to String and use explicit java.lang.String around converting means to make explicit reference to java.lang.String in all places inside the package org.logstash.settings.* .

How to test this PR locally

  • run of CI is one good test.
  • run Logstash instance, it uses plenty of string settings.
  • switch some string setting to an invalid value and verify it reports the error. For example tinker with config.field_reference.escape_style in config/logstash.yml

Related issues

@andsel andsel self-assigned this Oct 17, 2024
@andsel andsel force-pushed the feature/string_setting_to_java branch from f1abaf3 to 8ffcede Compare October 29, 2024 18:18
@andsel andsel force-pushed the feature/string_setting_to_java branch from c3bcbd5 to 0602b98 Compare November 12, 2024 10:10
@andsel andsel changed the title Reimplemented LogStash::String setting in Java Reimplement LogStash::String setting in Java Nov 12, 2024
end
end
context 'to an invalid value not in the allow-list' do
let(:possible_strings) { %w(this that)}
let(:candidate_value) { "another" } # wrong type, expects String
it 'is an invalid setting' do
expect { nullable_setting.validate_value }.to raise_error(ArgumentError, a_string_including("Invalid value"))
expect { nullable_setting.validate_value }.to raise_error(java.lang.IllegalArgumentException, a_string_including("Invalid value"))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andsel andsel force-pushed the feature/string_setting_to_java branch from 91e2048 to 180d597 Compare November 12, 2024 16:04
Copy link

@andsel andsel marked this pull request as ready for review November 13, 2024 09:16
@andsel andsel linked an issue Nov 13, 2024 that may be closed by this pull request
@kaisecheng kaisecheng self-requested a review January 22, 2025 17:02
Copy link
Contributor

@kaisecheng kaisecheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a minor suggestion on renaming StringSetting. I like your way to test with log appender. I will do more tests tmr.

import java.util.Collections;
import java.util.List;

public class StringSetting extends BaseSetting<String> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The setting classes have migrated Boolean, Coercible and NullableString to java. Do you think we can keep this class as String instead of StringSetting?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to do that but then every instance of Java String needs to be referenced by its full classname.
In this case I think that having the suffix Setting make more explicit in the codebase to which class we are referring.
For Boolean was easier and less impacting. I think that for Logstash settings which names collides with Java standard type we could use the Setting postfix.
WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh... naming is hard. Could we use SString ? The first S stands for Setting.
StringSetting sounds like referring a different thing comparing to Boolean.
😮‍💨 I can accept StringSetting if you think it is more comfortable

Copy link
Contributor Author

@andsel andsel Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could it worth to rename to SettingString so that the type part is last and maybe recall more that this class is closely related to the string type, like Boolean ?
I think that the issue is the original naming, type names has strong meaning in programming languages, so I would have used something else, maybe including the Setting suffix in every class.
WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a prefix for every class would be good, eg SettingBoolean, SettingString, SettingNullableString

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I rename StringSetting to SettingString for this PR then I'll create a follow up PR for the others

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tracked in #16946

Copy link
Contributor

@kaisecheng kaisecheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested locally and it works as expected. I hope we can find another name for Logstash::Setting::String

Copy link

@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

History

cc @andsel

@andsel andsel merged commit 03b11e9 into elastic:main Jan 24, 2025
6 checks passed
@andsel
Copy link
Contributor Author

andsel commented Jan 24, 2025

@logstashmachine backport 8.17

@andsel
Copy link
Contributor Author

andsel commented Jan 24, 2025

@logstashmachine backport 8.16

andsel added a commit to andsel/logstash that referenced this pull request Jan 24, 2025
Reimplements `LogStash::Setting::String` Ruby setting class into the `org.logstash.settings.SettingString` and exposes it through `java_import` as `LogStash::Setting::SettingString`.
Updates the rspec tests in two ways:
- logging mock is now converted to real Log4J appender that spy log line that are later verified
- verifies `java.lang.IllegalArgumentException` instead of `ArgumentError` is thrown because the kind of exception thrown by Java code, during verification.
andsel added a commit to andsel/logstash that referenced this pull request Jan 24, 2025
Reimplements `LogStash::Setting::String` Ruby setting class into the `org.logstash.settings.SettingString` and exposes it through `java_import` as `LogStash::Setting::SettingString`.
Updates the rspec tests in two ways:
- logging mock is now converted to real Log4J appender that spy log line that are later verified
- verifies `java.lang.IllegalArgumentException` instead of `ArgumentError` is thrown because the kind of exception thrown by Java code, during verification.
@andsel
Copy link
Contributor Author

andsel commented Jan 24, 2025

8.17: #16947
8.16: #16948

@kaisecheng
Copy link
Contributor

@andsel please also backport to 8.x

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.

Port the String Setting implementation from Ruby to Java
4 participants