-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Forbid the single argument Environment constructor in production code #27235
Forbid the single argument Environment constructor in production code #27235
Conversation
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.
LGTM assuming CI is happy :)
I wonder how much work it would be to move all uses of |
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 left a suggestion for exploration.
Only tests should use the single argument Environment constructor. Production code (beyond initial Bootstrap) should always use the same Environment object that Node.getEnvironment() returns. This Environment is also available via dependency injection.
…ion code" This reverts commit d8fdce8f0c908fc43f2a58c849f32f0cc8120aba.
This ensures that only the two argument constructor can ever be used in production code.
25becd9
to
4f401a1
Compare
Thank you @droberts195! |
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.
LGTM.
Only tests should use the single argument Environment constructor. To enforce this the single arg Environment constructor has been replaced with a test framework factory method. Production code (beyond initial Bootstrap) should always use the same Environment object that Node.getEnvironment() returns. This Environment is also available via dependency injection.
* master: Backport the size-based index rollver to v6.1.0 Add size-based condition to the index rollover API (elastic#27160) Remove the single argument Environment constructor (elastic#27235)
* 6.x: test: Break apart the multi type aspect of rolling upgrade tests, Upgrade to Jackson 2.8.10 (#27230) [Docs] Fix minor paragraph indentation error for multiple Indices params (#25535) Fix inconsistencies in the rest api specs for `tasks` (#27163) Adjust RestHighLevelClient method modifiers (#27238) Add more information on `_failed_to_convert_` exception (#27034) Remove ElasticsearchQueryCachingPolicy (#27190) Backport the size-based index rollver to v6.1.0 Add size-based condition to the index rollover API (#27160) Remove the single argument Environment constructor (#27235) Fix RestGetAction name typo
Hi there! Following up on this change, how would a plugin class access the Environment variable? Adding
My plugin needs access to I should note calling |
You can use the 2 argument constructor for your plugin, that takes Line 37 in be74f11
The problem with passing |
That indeed seems to work, thanks! |
Only tests should use the single argument Environment constructor.
Production code (beyond initial Bootstrap) should always use the same
Environment object that Node.getEnvironment() returns. This Environment
is also available via dependency injection.