Skip to content

Conversation

wujimin
Copy link
Contributor

@wujimin wujimin commented Jul 24, 2017

previous name is "vert.x-eventloop-thread-{number}"
new name is "{name}-vert.x-eventloop-thread-{number}"

previous name is "vert.x-eventloop-thread-{number}"
new name is "{name}-vert.x-eventloop-thread-{number}"
@coveralls
Copy link

Coverage Status

Changes Unknown when pulling ee5356d on wujimin:vertx-eventloop-name into ** on ServiceComb:master**.

Copy link
Contributor

@liubao68 liubao68 left a comment

Choose a reason for hiding this comment

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

为了实现可维护性需求使用反射,增加了对第三方的依赖和耦合,个人偏好不做这样的优化。

@wujimin
Copy link
Contributor Author

wujimin commented Jul 25, 2017

yes
but vertx did not provide mechanism to do this
and we have automatic test case to ensure this is no problem.

@liubao68
Copy link
Contributor

return Vertx.vertx(vertxOptions) is a factory method , after change, we new a object our self, most of time UT can not guarantee this

@wujimin
Copy link
Contributor Author

wujimin commented Jul 26, 2017

UT do not care for this , thread name only for runtime.

@wujimin
Copy link
Contributor Author

wujimin commented Jul 26, 2017

just only one test case check the thread name , this case added in this PR

@WillemJiang WillemJiang merged commit 1362858 into apache:master Jul 27, 2017
@wujimin wujimin deleted the vertx-eventloop-name branch August 11, 2017 09:18
@WillemJiang WillemJiang modified the milestone: 0.2.0 Aug 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants