We Keep Coding

When to use ServletBearerExchangeFilterFunction and when ServerBearerExchangeFilterFunction?

I just stumbled upon the fact that there are two classes that apparently do very similar things and it is not clear to me from the documentation when to use which.
ServletBearerExchangeFilterFunction and
ServerBearerExchangeFilterFunction
both live in the same package of Spring-Boot-Security-oauth2-resource-server and serve the same purpose of transporting a bearer token from the Context into outgoing http requests.
From the names I would have guessed that the Servlet option would be used for non Reactor projects while the Server version would be used with project Reactor. However that doesn't seem to be the case. At least the Servlet version seems to be working with Spring-WebFlux.
Can anyone please explain when to use which implementation?

We apparently had a false observation when using the ServletBearerExchangeFilterFunction. I corrected this in the original Question.
It turns out the ServletBearerExchangeFilterFunction can be used to configure a WebClient for use in a WebMVC (Thread based request processing) context while the ServerBearerExchangeFilterFunction works when using SpringWebFlux.

Java web development: Sessions are not saved between requests and a new JSESSIONID is created

I have a problem that I have been scouring the internet for the past few days. I have found people with similar problems but whos solutions didn't advance my state.
What is most irritating is that I have been working with this before, without problems or any blocks.
The thing is that my sessions on my java web application, is either getting deleted inbetween requests or not create correctly to begin with.
Some simple trouble shooting:
I can create and use cookies just fine.
Every time I refresh or follow a link to a servlet or jsp, the
jsessionid is getting a new id.
On chrome, I can not see the session cookie (but other cookies I
can).
On firefox, I can see the session cookie (and also that its id is
changing at every request).
I have had this to work before without even giving it as much as a single thought.
I just use the:
In jsp I just session.get/setAttribute()
In servlet I just request.getSession()
I have also looked into the getSession(boolean created), but as far as Im concerned getSession() should do it for me?
My server is running Tomcat 7 and have Servlet 3.
I can see the with servlet 3, that I have to declare some things in the web.xml file, my session config is as follows:
<session-config>
<session-timeout>30</session-timeout>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
You think im doing something wrong in my code? it seems far to simple, and have used it times before. But this is the first time I have had the task to also setup the servers configuration.
This is my first post on stackoverflow, have found many answers before here, and hope someone can tell me where I am being an idiot. Hope I have given comprehensive details. Thanks in advance.

Sometimes its hard to search for a solution, when you don't exactly know what the problem is.
The problem was with the apache proxy setup for tomcat.
Here is the link for anyone else that might stumble upon my way of formulating the problem.
Apache 2.2 Virtual hosts + Tomcat 7 applications
adding ProxyPassReverseCookiePath /testapp /
to the httpd config.

Does s:url (in Struts2) not do url-rewriting like c:url does in case cookies are disabled?

The Servlet API resorts to URL rewriting if cookies are disabled.. and every URL that we provide in our JSPs must be inside c:url for this to be in effect. But, in Struts 2, there is an equivalent tag s:url, but its documentation says nothing about automatically adding url-rewriting information (if required) to the url. Is its behaviour similar in this regards to c:url, or do we have some other means to achieve the same effect in Struts 2 ?
I am using Struts 2.1 url tag reference from here
Clarification : In case that the user disables cookies, the other option is to append the jseesionid to each url that is there on the page. c:url handles that for us. My question is that whether s:url does the same thing for us. I was worried as its not mentioned in the documentation link I provided above.

Yes struts2 will do this too. Simply disable cookies and you should see a session id is put into the url (when using s:a tags, I have not tested url tags). I'm glad you added clarification because this is url writing. Url rewriting is done as urls come into the server, where they are then rewritten by certain rules generally so they get directed to the right place within the server(which is not at all what is happening here).
Edit: Thanks to Daud, the correct term is url-rewiting. This is because session management is handled by the container level, although struts2 can manipulate what the session contains, it is the container which provides the session via a "session manager" object and determines how persistence is best managed (including generating the jSession Id).
For details on this for glassfish: http://docs.oracle.com/cd/E18930_01/html/821-2418/beaha.html#beahf
For details on this for tomcat: http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Disable_Session_Persistence
For other containers simply google: Container_Name + "session manager"

Importing secured content using the jstl import tag and have the OSIV filter working correctly

Anyone ever tried the following? (and was successful)
In a web application (A), I am using the <c:import> tag to get secured content from another web application (B) running on the same application server (WebSphere 7). Both apps use Hibernate and Spring's OSIV filter.
Looking at the import tag source, I see that the strategy is that if the url is relative then it includes the content using RequestDispatcher.include() .If the url is absolute, the code opens a URLConnection.
Since I need to keep track of the remote user, I can't do the following:
<c:import url="http://host:port/B/getContent">
Doing
<c:import url="/getContent" context="/B">
instead would work. But with this approach I am not hitting Spring's OSIV filter configured in B. The original (importing) request in A does go through the OSIV filter but it has no effect in B. Hence I am getting the usual "No session or session closed" error for lazy initializations of entities.
I am bit in a catch 22 here and I am wondering if what I am trying to do is actually feasable according to my requirements.
The bottom line is that I did manage to get what I wanted by aggregating my content directly from the client using Dojo, (I am using SSO so the identity of the user gets carried) but I would prefer the other way if it was possible.

Deploying Struts2 Application without ContextPath

I've got a struts2 application running under a contextpath "/path" on my local tomcat without problems. When I deploy it on a webserver (using a proxy to redirect from "http://www.domain.com" to "myserver:8080/path/") Struts does all kinds of strange things.
First, it includes the context in -tags. That can be turned off by an attribute. But sadly, it also includes the path in the action attributes of my forms, so a login form points to "http://www.domain.com/path/login.action" instead of "http://www.domain.com/login.action" ...
Is there a possibility so somehow change the default context that is added here or turn this off for forms? (I'd like to keep the -tags, only way round seems to be to use default HTML forms.) Thanks in advance!

I found that others also had the problem, but the framework makers don't seem to think that this is an issue. My solutions:
use includeContext="false" in all s:url-tags
instead of the s:form tag, use a usual form, set the action to "actionname.action" and include a simple table with tablerows () for each field. You still can use s:textfield and such.
sadly HTTP sessions won't work anymore as they get set for the path "/path" (the ApplicationPath). This is due to the cookie that saves the JSESSIONID being set to /path. This means that your visitors will only get session variables stored when they're at http://www.domain.com/path/login.action and that those will be lost when they get redirected back to http://www.domain.com/interestingstuff.action ... my solution is a hack that requires setting the JSESSIONID cookie clientside via JavaScript as described here: Struts2: Session Problem (after reverse proxy)
Hope this helps someone ... if you find nicer solutions, please let me know. :-)

Though am answering very late to this question, but I reached this page recently when I was facing the same problem.
The application that I was working upon was appending the context-root viz. 'myContextRoot' to my url on localhost and it was working perfectly there. For eg., as mentioned above the action 'myAction' was becoming
http://localhost:8050/myContextRoot/myAction.action
But the moment I deployed it on a server, it stopped working, then after searching like hell, I found a solution for me. I am deploying an EAR file on glassfish and there we have a file application.xml. In application.xml I had a tag 'context-root' whose value was 'myContextRoot' which I changed to '/' and after that I got my url as on localhost and
Hope it may help :)