-
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
Replace def #{type}_func
with define_singleton_method
#4298
Conversation
def #{type}_func
with define_singleton_method
693f709
to
6cf2950
Compare
LGTM, just waiting for #4254 to merge in |
@@ -15,6 +15,21 @@ def close | |||
end | |||
end | |||
|
|||
class DummyInputGenerator < LogStash::Inputs::Base |
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.
we install the generator plugin as part of the core plugins need for test, https://github.com/elastic/logstash/blob/master/rakelib/default_plugins.rb#L113-L121 any reason not to redefined here? you know I would like our make our test plugin free, only use mocks/stubs/dummy (pick your name), but if we require it for now I think it would be better to stick to one usage. what do you think?
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 was thinking to use the generator but I have checked the logstash-core
gemspec and it doesn't include the generator plugin and the only test in logstash-core that require the generator
is the pipeline_reporter_spec
.
Its not obvious that the generator is available in the context of theses specs 😞
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 know is not obvious, is in the file I shared, 👍 I understand. I think we should have only 1 way if possible, right? what do you think?
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.
Well, lets keep the DummyGenerator, since we don't need a dependency for that and you were proposing to move away. This also in line with the actual dummy plugin in the current pipeline_spec
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.
are we already ok on going away from plugins to be used in specs? I don't think we agreed, even if I love the idea. not sure what to think.
@purbon Concerning this PR against master vs the branch, let me check If I can do it agains't master. |
I will remake this PR against master |
9dd0d6f
to
d4bea94
Compare
updated with the review, @andrewvc do you want to cherry-pick this or I can create the PR against a feature branch? |
LGTM |
Hey @ph are you planning on rebasing this? |
43b012a
to
b259cdd
Compare
rebased with master @andrewvc ! |
@@ -47,6 +47,10 @@ def initialize(params={}) | |||
|
|||
def register | |||
end | |||
|
|||
def threadsafe? | |||
false |
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 don't think this currently exists as an API. In https://github.com/elastic/logstash/pull/4391/files#diff-3d93d6656c81049b6de7a09dbe141a46R30 I added a new method Outputs/Base.declare_threadsafe!
that would declare this at the class level.
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.
let me check that, if its needed, I think I had an error without it.
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.
You were right, I think at the time I have created the pr it was required.
b259cdd
to
4d83693
Compare
updated with your comment @andrewvc |
let(:pipeline2) { LogStash::Pipeline.new("input { generator {} } filter { dummyfilter {} } output { dummyoutput {}}") } | ||
|
||
it "should handle evaluating different config" do | ||
expect(pipeline1.output_func(LogStash::Event.new)).not_to include(nil) |
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.
This could use a comment explaining why we're checking for it not to be nil.
Could use an explanatory comment, but after that LGTM! |
When you run multiples pipeline and the config code get evaluated, on every evaluation the class cached is clear, everytime you were calling a `func` method you had the latest evaluated code. The `filter_func` and the `output_func` need to be unique for every instance of the pipeline, this PR replace the `def` with a `define_single_method` call ensuring the uniqueness of the code on every instance. This PR is based on #4254
4d83693
to
c032468
Compare
Added a comment! |
When you run multiples pipeline and the config code get evaluated, on every evaluation the class cached is clear, everytime you were calling a `func` method you had the latest evaluated code. The `filter_func` and the `output_func` need to be unique for every instance of the pipeline, this PR replace the `def` with a `define_single_method` call ensuring the uniqueness of the code on every instance. This PR is based on #4254 Fixes #4298
When you run multiples pipeline and the config code get evaluated, on every evaluation the class cached is clear, everytime you were calling a `func` method you had the latest evaluated code. The `filter_func` and the `output_func` need to be unique for every instance of the pipeline, this PR replace the `def` with a `define_single_method` call ensuring the uniqueness of the code on every instance. This PR is based on #4254 Fixes #4298
When you run multiples pipeline and the config code get evaluated, on
every evaluation the class cached is clear, everytime you were calling a
func
method you had the latest evaluated code. Thefilter_func
andthe
output_func
need to be unique for every instance of the pipeline,this PR replace the
def
with adefine_single_method
call ensuringthe uniqueness of the code on every instance.
This PR is based on #4254