SessionRepositoryFilter - problem with renewing session

Maybe i'm stupid a little bit, but i have made a lot of configuration with spring.

After a day of trying, i made a dirty workaround. To be honest i thought that i can rewrite the SessionRepositoryFilter faster than deal with it.

In my system users can have multiple profiles, and without login they can switch between them.
Profiles has different roles attached. So it's a little bit linux "su", but with the same credentials.
Profiles for task separation, not admin related.

The SessionRepositoryFilter needs to be splitted up i think avoiding inner final classes for SessionRepositoryRequestWrapper.

public HttpSessionWrapper getSession(boolean create) {
...
String requestedSessionId = getRequestedSessionId();
if (requestedSessionId != null
&& getAttribute(INVALID_SESSION_ID_ATTR) == null) {
S session = getSession(requestedSessionId);
if (session != null) {
this.requestedSessionIdValid = true;
currentSession = new HttpSessionWrapper(session, getServletContext());
currentSession.setNew(false);
setCurrentSession(currentSession);
return currentSession;
}
...
if(create != true)
{
return
}
...
create session
...
}

I would have liked to invalidate a session and create a new one at the same time.

In the controller i have made the following, as when you invalidate a session, you cannot renew it.
1,
I have called setAuthentication populating a new details. (principal/credentials are not changed in my case, so i'm copying over!!!)
2,
request.getSession().invalidate();
request.setAttribute(INVALID_SESSION_ID_ATTR, "true");
request.getSession(true);

Any idea, how i can achieve that goal without dirty hacks, or i have found a real bug?

Start with SessionRepositoryFilter and its inner SessionRepositoryRequestWrapper, especially getSession(boolean create) and the invalidate/create sequence described in the controller. Determine whether invalidating and renewing a session should be supported without the INVALID_SESSION_ID_ATTR workaround; no specific test or file path is provided, so the expected behavior needs clarification before implementation.