Open jerseyrobot opened 7 years ago
@glassfishrobot Commented Reported by fabrizio.cucci
@glassfishrobot Commented fabrizio.cucci said: I was looking into the code and I may have found the issue.
When the application starts for the first time, the ApplicationHandler#initialize method is invoked, which in turn does:
// Configure binders and features. runtimeConfig.configureMetaProviders(locator);
That results in a call to the CommonConfig#configureMetaProviders which does:
// Next, configure all features configureFeatures(
locator,
new HashSet<FeatureRegistration>(),
resetRegistrations());
The CommonConfig#resetRegistrations method copies the list of FeatureRegistration and then clears the list:
private List<FeatureRegistration> resetRegistrations() {
final List<FeatureRegistration> result = new ArrayList<FeatureRegistration>(newFeatureRegistrations);
newFeatureRegistrations.clear();
return result;
}
When the Container#reload method is invoked, because the same ApplicationHandler#runtimeConfig is used, my ImmediateScopeFeature won't be in the CommonConfig#newFeatureRegistrations anymore and therefore won't be configured.
I don't have a big picture of the codebase but the two options that I can think of are:
Of course, calling the overloaded version of Container#reload(ResourceConfig) works fine because the RuntimeConfig is not reused.
By the way, I would be glad to contribute the fix with some hint.
@glassfishrobot Commented fabrizio.cucci said: Also, after re-reading my own report, I realized something else. In my case, the ImmediateScopeFeature is removed from the CommonConfig#newFeatureRegistrations and this is the reason why it's not re-configured on Container#reload(). But this means that, potentially, any other custom feature won't be re-configured upon Container#reload().
@glassfishrobot Commented This issue was imported from java.net JIRA JERSEY-3225
@fabriziocucci Commented pavelbucek said (on 17 Mar 2017, at 10:33):
Hi Fabrizio,
I'm sorry, we are currently not looking into mentioned issue.
I briefly looked into the code and I believe that CommonConfig should be recreated during the reload, but I'd need to debug it to be sure.
Would it be possible to extract your usecase to a minimal reproducer and share it?
Thanks and regards, Pavel
@fabriziocucci Commented fabrizio.cucci said (on 17 March 2017 at 12:54):
Hi Pavel,
thanks a lot for your prompt reply.
Is the gist attached to the issue description sufficient?
I'll post the link here too: https://gist.github.com/fabriziocucci/5660af43ebeb7ec04f20ed293cd5676f
Thanks, Fabrizio
@fabriziocucci Commented Added missing updates sent on mailing list since one particular comment from Pavel could be useful in resolving this:
I briefly looked into the code and I believe that CommonConfig should be recreated during the reload, but I'd need to debug it to be sure.
@fabriziocucci Commented
@mpotociar I wanted to edit title and description to highlight the fact that this is not a HK2-related issue but actually any feature is not re-configured upon org.glassfish.jersey.server.spi.Container#reload
.
Unfortunately, I'm not able to do that because the issue was physically reported by glasshfishrobot
.
Anyway, please find below a more general test that proves my point:
Affected Versions:
I managed to reproduce this with a simple gist.
The code is really self-explanatory but basically I'm binding a service with Immediate scope and then trying to reload the application using the org.glassfish.jersey.server.spi.Container#reload method.
The result is the following exception:
Affected Versions
[2.25.1]