[
https://issues.apache.org/jira/browse/MNG-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539515#comment-17539515
]
ASF GitHub Bot commented on MNG-7401:
-------------------------------------
gnodet commented on PR #743:
URL: https://github.com/apache/maven/pull/743#issuecomment-1131622335
> We have TLS-based solutions in past releases and we had to revert. What
makes this one different?
It's not a new TLS, it's a move of the existing TLS from SessionScope to
MavenSession.
The problem I'm trying to solve is really MNG-7474 : the fact that session
scoped beans are not singletons anymore, since the introduction of _multiple_
sessions when introducing the concurrent builds. This is what introduced the
TLS in the SessionScope, thereby breaking its purpose, i.e. beans are not
cached within the session scope.
So there are several solutions to this problem, but I think the SessionScope
is useless in the current form. So if we don't want to use a single session
and keep things the way they are, I'd need to introduce a more global scope
with a real singleton session object. We can't simply change the SessionScope,
because beans are injected with the MavenSession, so if we want singletons, we
need to have a consistent MavenSession object across mojo executions, which is
not the case because of the multiple session clones.
So the possibilities are:
* revert the use of multiple sessions, i.e. use a single session
throughout the whole build, which is what this PR is about. The possible
drawback is breakages of code that would use `MavenSession.getCurrentProject()`
from a different thread
* introduce a new concept of singleton session + scope. if we want it
immutable, it would basically be the MavenSession without the current project.
The obvious drawback
* do nothing to fix the problem: this is a possibility and I'd have to
work around the problem in m-build-cache-e by keeping state inside the
MavenSession, or most probably in the `RepositorySystemSession.getData()`
structure. In such a case, I think it would be better to deprecate the
`@SessionScope` and related classes.
I think the cleaner state would be to fix the `@SessionScope` and use a
singleton for `MavenSession` because that's semantically the most desirable
state. Scopes are natural for DI, so it makes sense to use them, and the
`MavenSession` cloning stuff has only been introduced to solve the
`getCurrentProject()` problem. We should maybe also deprecate this method and
suggest that plugins should have the project injected in a field. It would be
difficult to get rid of it in the very short term, as that one is used a lot
internally for the moment. We could also move it the `LegacySupport` along
with the access to the current session.
> Make MavenSession#getCurrentProject() using a thread local
> ----------------------------------------------------------
>
> Key: MNG-7401
> URL: https://issues.apache.org/jira/browse/MNG-7401
> Project: Maven
> Issue Type: Improvement
> Reporter: Christoph Läubrich
> Priority: Major
> Fix For: waiting-for-feedback
>
>
> I noticed that a session is often cloned due to change the current project
> for a while.
> As this works for everyone passing down the session, consumers of the "upper
> session" (e.g. a SessionScoped Component) would never see this if they are
> (indirectly) called and e.g. use Session#getCurrentProject().
> I wonder if MavenSession could simply use a ThreadLocal for the
> currentProject (that is shared accross all cloned sessions), that way one
> would always get the correct value.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
