Develop Reference

How to prevent JSESSIONID from being created if using DefaultCookieSerializer of spring 5.X with Tomcat 8

I am migrating to spring 5.X and configured DefaultCookieSerializer with cookieName "CUSTSESSION" for a domain called colombiaonline.com. This session is stored in redis using RedisHttpSessionConfiguration.
springSecurityFilterChain is defined after springSessionRepositoryFilter in application context of spring.
Application is deployed on Tomcat 8. (context.xml sessionCookieDomain is set as "colombiaonline.com")
URL for application is dev.colombiaonline.com.
Now my issue is --
Two cookies are created
CUSTSESSION is created with domain colombiaonline.com as configured.
JSESSIONID is created for domain dev.colombiaonline.com which is not expected.
How to stop JSESSIONID from being created as it is causing problem?

I am able to fix the issue. It was only browser cache that was causing this issue. Configuration was correct and once I opened my site on incognito it worked for me.
However there is one more thing that we need to take care of is "sameSite" attribute. Default value for it is "Lax" which is different from "None". If you hop between sites and want session to be managed properly, configure sameSite properly as in my case earlier it was none but after migrating to 5.x it was set to "Lax" which was causing problem.
Refer https://security.stackexchange.com/questions/168365/is-setting-same-site-attribute-of-a-cookie-to-lax-the-same-as-not-setting-the-sa

session distributable EAP it's not working

I have one master and two slave into domain modes, using and httpsession and distributable into web.xml but the session is not shaing into domains, Im access one node and work, but when access the other node the session is not sharing.
the configuration is the following
1 master
2 slaves(slave1, slave2)
1 server group (demo)
2 nodes (node11 server slave1, node21 server slave2 )
When access node 11 and make the login, and then chage to node21 the session is not persisted, and the result is null.
and try with another app for session but have the same issue
jboss eap is 7.2 and jdk is open jdk 1.8
I try using two different application of session sharing, and none of work.
Im try the same on on server on different ports and the session was shared

You need to add <distributable/> tag in your web.xml. You may need to enable session replication on your JBoss domain server as well. Refer https://developer.jboss.org/thread/277766 for more details.
You should also read JBoss EAP documentation on this Configuring high availbility

I'm not sure what you mean by master vs slave modes. This is not a concept on which EAP clustering relies.
Additionally, domain mode is about management, not about clustering. These are completely orthogonal concepts.
From a management perspective, servers within a given server-group share the same configuration. Generally, if the server-group is configured to use an "ha" profile (which defines a JGroups subsystem which is the starting point for cluster configuration), and multicast is allowed on your network, servers should form a cluster out-of-the-box.
If this is not happening, look to your server logs to figure out what is happening, and to the docs for configuring JGroups discovery w/out multicast.

Strange behaviour of Tomcat 8.0.32: sometimes it ignores cookies. Can it be somehow debugged?

There is a very weird problem with our Tomcat 8.0.32 installed under Ubuntu 16.x.
This problem starts to happen accidentally and exists until tomcat server restart (so it is reproducible after it begins happen).
What happens, is that some of the requests send by timer from JS application with proper cookie: JSESSIONID= value are improperly processed: the Tomcat can not find Session object for it (from Spring MVC layer it means, that user is not authenticated). All requests with the same JSESSIONID being sent before this broken request, and all requests being send after (again with the same value of session id) - they all work fine!
We also certainly see that all headers in that request are correct (they are printed out by our application in some Filter), but Session object is not restored.
So basically it sounds like under some circumstances the Tomcat starts ignoring JSESSIONID from the requests sent via redirect from another server. And again, this does not happen always, only after some time of web-application life.
I will not provide any code here or configuration settings. First, because it looks like the poor Tomcat problem, second, because configuration is standard (out of the box after apt-install).
My question is: how can we configure the Tomcat in order to log all operations related to the JSESSIONID processing? Like that it finds session for the given ID, or does not and so on.
UPD: This never happens with more newer version of Tomcat 8.5.5. But due to some reasons it can not be updated on that particular server. My current goal is to collect evidences about this behaviour to be sure that it is a bug, or some strange default configuration that tomcat installation.

According to the docs https://tomcat.apache.org/tomcat-8.0-doc/logging.html
to enable debug logging for part of Tomcat's internals, you should configure both the appropriate logger(s) and the appropriate handler(s) to use the FINEST or ALL level. e.g.:
org.apache.catalina.session.level=ALL
java.util.logging.ConsoleHandler.level=ALL

Spring JMX - Purpose of <context:mbean-server>

I am going through 'Chapter 20 - Managing Spring bean with JMX' from the book 'Spring In Action' 4th Edition by Craig Walls. There is one paragraph in this chapter on page 527.
From whence the MBean server?
As configured, MBeanExporter assumes that it’s running in an application server (such as Tomcat) or some other context that provides an MBean server. But if your Spring application will be running standalone or in a container that doesn’t provide an MBean server, you’ll want to configure an MBean server in the Spring context.
In XML configuration, the <context:mbean-server> element can handle that for you. In Java configuration, you’ll need to take a more direct approach and configure a bean of type MBeanServerFactoryBean() (which is what does for you in XML).
I have couple of questions on the above paragraph.
Does it mean that when we are running the application on server like Tomcat, <context:mbean-server> declaration is no longer required?
If above statement is true, who takes care of locating the MBean server when we are running on server like Tomcat or any other application server?
Thanks in advance!

That information is a little out of date...
or some other context that provides an MBean server.
Starting with Java 5 (if I recall correctly), the JVM has a built in MBeanServer. Prior to that, you had to be running in an App server, or provide some other MBeanServer such as mx4j.
Regardless, you still need the server bean declaration; it tells Spring which server to use (the underlying MBeanServerFactoryBean's locateExistingServerIfPossible is set to true by the XML namespace parser. If that flag is false, the factory bean would create an additional MBeanServer.

Configuring Websphere 7 to use single JAX-WS service instance for all requests

While it's well known that Websphere's JAX-WS implementation is based on Axis2, I have had trouble finding information how to set "scope" for the service.
In axis 2 scope can be defined using services.xml. Is this file also available in Websphere?
http://axis.apache.org/axis2/java/core/docs/axis2config.html
scope: (Optional Attribute) The time period during which runtime information of the deployed services will be available. Scope is of several types- "application", "soapsession", "transportsession", "request". The default value (if you don't enter any value) will be "request"

It seems it is possible to do what you want in WebSphere (not using services.xml):
Configuring the scope of a Web service port using wsadmin scripting
Did not try it myself, also, could not find such settings in the admin console or deployment descriptor of some kind but that might be possible as well.