-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Conversation
f1abaf3
to
8ffcede
Compare
c3bcbd5
to
0602b98
Compare
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")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…stead of Ruby one
…ingWithDeprecatedAlias spec test.
…when it closes the logger context
Reworked log capture in setting_with_deprecated_alias_spec to use Logger's addAppender and a spy appender implementation. This leverages the idea to don't reconfigure the Log4J with a custom build configuration, but simply adding an appender that could spy the appended lines to a logger.
…e also in runner_spec, removing the programmatic configuration way
91e2048
to
180d597
Compare
Quality Gate passedIssues Measures |
There was a problem hiding this 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> { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tracked in #16946
There was a problem hiding this 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
Quality Gate passedIssues Measures |
💚 Build Succeeded
History
cc @andsel |
@logstashmachine backport 8.17 |
@logstashmachine backport 8.16 |
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.
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 please also backport to 8.x |
Release notes
[rn:skip]
What does this PR do?
Reimplements
LogStash::Setting::String
Ruby setting class into theorg.logstash.settings.StringSetting
and exposes it throughjava_import
asLogStash::Setting::StringSetting
.Updates the rspec tests in two ways:
java.lang.IllegalArgumentException
instead ofArgumentError
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
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration files (and/or docker env variables)Author's Checklist
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 inlogstash/logstash-core/spec/logstash/runner_spec.rb
Line 269 in 467ab3f
Appender
and reconfigure logs?LogStash::String.new
[ ] Renameconverting means to make explicit reference toStringSetting
toString
and use explicitjava.lang.String
aroundjava.lang.String
in all places inside the packageorg.logstash.settings.*
.How to test this PR locally
config.field_reference.escape_style
inconfig/logstash.yml
Related issues