The method SpringApplication#refresh
is only called by SpringApplication#refreshContext(ConfigurableApplicationContext)
.
So the application context instance passed to SpringApplication#refresh
will always be a subclass of ConfigurableApplicationContext
, which has a method 'refresh'.
No need to assert that using Assert.isInstanceOf(AbstractApplicationContext.class, applicationContext);
.
It could be simplified like this:
protected void refresh(ConfigurableApplicationContext applicationContext) {
applicationContext.refresh();
}
Further more, the field applicationContextClass
of SpringApplication
is also declared as Class<? extends ConfigurableApplicationContext>
.
I think it is reasonable enough to modify the method signature.
Comment From: wilkinsona
Thanks for the suggestion. While I agree that things could perhaps be simplified a little here, it would technically be a breaking API change. I'm not sure that the small benefit of the change justifies making it. May I ask what prompted you to open the issue?
Comment From: justmehyp
Thank you for your reply.
Well, I am a number-one fan of Spring framework. Since I use it, I hope it gets better. I read the source code, then I feedback something I think is better. Sometimes I am stubborn about keeping the code clean, if it makes me confused ...
Yes, it is a breaking API change. But thankfully it is an internal API, not public. It is a protected
method, but no subclasses inherit SpringApplication
up to now.
I noticed that parameters of SpringApplication#afterRefresh
changed for introducing ApplicationArguments
and removing String[]
.
I think it is a good strategy. If you can't change it right away, I suggest you use this strategy again as a means of transition.
In 1.2.8.RELEASE, it is:
protected void afterRefresh(ConfigurableApplicationContext context, String[] args) {
runCommandLineRunners(context, args);
}
In v1.3.8.RELEASE, it is deprecated:
@Deprecated
protected void afterRefresh(ConfigurableApplicationContext context, String[] args) {
}
and you add a new method:
protected void afterRefresh(ConfigurableApplicationContext context, ApplicationArguments args) {
afterRefresh(context, args.getSourceArgs());
callRunners(context, args);
}
in v1.4.0.RELEASE, SpringApplication#afterRefresh(ConfigurableApplicationContext, String[])
was removed. Only SpringApplication#afterRefresh(ConfigurableApplicationContext, ApplicationArguments)
was retained.
Comment From: philwebb
it is an internal API, not public. It is a protected method, but no subclasses inherit SpringApplication up to now.
I'm afraid we need to treat it as a public API. Just because we don't have a SpringApplication
subclass in our code does not mean that someone is not relying on it.
I think it is a good strategy. If you can't change it right away, I suggest you use this strategy again as a means of transition.
I'm not sure that the additional argument would be in this case. We'd probably need to introduce a new method with a different name.
Comment From: justmehyp
I think you are right. In this case, a new method such as doRefresh
could be introduced:
protected void doRefresh(ConfigurableApplicationContext applicationContext) {
refresh(applicationContext);
}
Then mark refresh
as deprecated:
@Deprecated
protected void refresh(ApplicationContext applicationContext) {
Assert.isInstanceOf(AbstractApplicationContext.class, applicationContext);
((AbstractApplicationContext) applicationContext).refresh();
}