Fix bug where policy context was not cleared before policy retranslate - #25728
Conversation
| <!-- | ||
| The Arquillian connector that starts GlassFish and deploys archives to it. | ||
| --> | ||
| <dependency> |
There was a problem hiding this comment.
This creates cyclic dependency. It depends on GlassFish project, now Glassfish project depends on the container too. It seems to me that there is yet bit more redundant things.
Can I merge it to application-tests instead? We also don't need to have new pom (or two) for every test.
EDIT: Ok, we already have the dependency in TCK submodules ... I forgot about this aspect, however as the plugin can support multiple GF versions, it is probably ok.
However I would still move it to application-tests.
There was a problem hiding this comment.
Ok, we already have the dependency in TCK submodules
yeah, it's modelled exactly after the TCK submodule. We don't have application-tests btw, but I think it's appserv-tests you mean then?
There was a problem hiding this comment.
We do for some 3 years ;-)
https://github.com/eclipse-ee4j/glassfish/tree/master/appserver/tests/application
| </description> | ||
|
|
||
| <dependencies> | ||
| <dependency> |
There was a problem hiding this comment.
I prefer to explicitly declare which specs we need here ...
There was a problem hiding this comment.
I took this particular app from another demo app I was working on, where just the EE dependency was more convenient. For here I can specify the exact APIs used indeed.
| @@ -0,0 +1,7 @@ | |||
| <?xml version="1.0" encoding="UTF-8" ?> | |||
| <beans xmlns="https://jakarta.ee/xml/ns/jakartaee" | |||
There was a problem hiding this comment.
Do we still need the beans.xml here?
There was a problem hiding this comment.
Nope, we indeed don't need it. Left-over from the app I took it from.
2 participants
When a servlet or filter is added dynamically, internally GlassFish triggers a Policy retranslate. This means indexing of URLs for permissions etc is done again.
Jersey happens to do such dynamic add, and thus triggers this retranslation.
We had a bug there, where the previous context was not properly cleared. This particularly meant that the "http request capturing lambda" was still the one from the first translation. After the retranslation, the lambda of the second context was given the http request, but the first one was still being used when application code asked for it. The first one was never given the request, so would always return null.
The request is used currently for the SecurityContext implementation of Soteria (although we are bound to change this in a later version). The included test therefor also looks at this stored request directly.