Win a copy of Java Database Connections & Transactions (e-book only) this week in the JDBC forum!

Kath Tharsas

+ Follow
since Aug 14, 2018
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Kath Tharsas

Rob Spoor wrote:It's also possible to use WebSockets without STOMP. See

Yeah but (as far as I can see) it does not come with Spring Security integration / authentication so i cannot send data over it. I definitely don't want to write my own authentication code and somehow integrate it into spring security myself.
1 month ago
Thanks, you guys helped me a lot.

I am already using websocket, but without STOMP, because it seemed extremly difficult to get a good/deep understanding of the principles behind stomp and all the endpoints rules and how its supposed to be used in a use-cases like mine. I found the Spring documentation for all of this extremely lacking. So currently i use pure, not authenticated websocket to send a "ping" to clients when new updates/events are available on the server, and use normal HTTP to get the updates.

Since my experience with STOMP was so bad, maybe i should look into SSE, since i need spring security authentication to work. Or I put the per-tab state into a hashmap inside the session with a "tab key" for each state that i give out the tabs. Anyway, i think my questions are answered.
2 months ago
Ok thanks so what you are saying is that i should make sure that i have different session cookies for different tabs?

Currently client side sessions seem to work with a cookie called "SESSIONID". I guess the page tells the browser the value for that cookie is or is that done by the browser itself? Haven't really worked with cookies yet apart from what Spring MVC and Spring Security do automatically.
2 months ago
I'm currently developing an open source webapp with Spring MVC and i am currently a bit helpless in regards to sessions.

My app needs to provide a (big) list of elements to the browser and when that is done, it needs to provide constant real-time updates to inform the browser of changes to the elements in the list. I did that by allowing my Spring sessions to register themselves at some data service to receive all element updates (basically listener pattern). When a session receives an update, it will store it in some buffer list and whenever the client/browser asks for updates, the updates in the buffer will be sent to the browser.

Example session code:

I inject these session into spring singleton controllers, as usual. Problem with that is, that if a user has multiple tabs open, the tabs will steal each others events, because as far as i can see a spring session is not per tab but per user (probably through cookies). Btw, there is an independent mechanism that tells the browser when to ask for updates, that is not the problem (using websocket for that currently).

Controller example:

I currently see only these three solutions:
Possible solutions:
- One session per tab (if that is possible with spring sessions somehow)
- Manage tab session state manually instead of using spring sessions
- Only allow one tab (not preferred)

Have you guys had to deal with stuff like this an maybe can advise me on how to do this properly? Is there some Spring magic that would provide an solution?
2 months ago
Yes, i noticed the behaviour you describe (i can't just overwrite the unexploded war) in Tomcat 7/8. I also have Tomcat 9 here for testing, ill try if what you describe works there, and see if that also deletes the external context.

Anyway, it seems to me that either the JSR's or Tomcats concept of the server-dependent deployment descriptor is lacking, because the concept of an "incomplete" context (or some kind of persistent config) is necessary in reality. And not allowing people to do this does not make sense imho as explained.
10 months ago
Well if that is how it was designed, it seems to be a very bad design. Like, what is the official way to supply external persistent config to your webapps, that works when you want to deploy the same webapp multiple times on one server? Don't tell me there is none and that i have to KNOW my the target environment at the time when i build my war file, because that makes no sense. That would mean i would have to build a war file for dev, one for staging, one for production, and additional ones for every kind of server that i would want to deploy my war on.

About the path: I could probably fiddle with my build so i can put my current project dir into the dev context instead of relative paths. Then i would not need relative paths at all.
10 months ago
Tomcat deleting context config on undeploy (and thus on redeploy because that includes undeploy) is documented, intended (sadly), and easily reproducable, see:

Also, i do not use relative paths in production. The example in OP is from my "dev" config, were i use embedded tomcat and the base is always the project directory (and if it changes, it doesn't really matter. Its just dev). The point is that i needs to be adjustable, and it needs to be adjustable per war, but not defined in the war.

So all in all, what you are telling me, is that i should use the manager webapp or http interface that maven/grade plugins are using? Well it seems to be only option left, i just hope that this doesn't delete my stuff, too.
10 months ago

I recently looked into ways how to make externalized config work with Tomcat 8.
To release a new version to our production Tomcat, I usually just login via FTP, delete the old webapp/war and upload the new webapp/war. AutoDeploy does the rest. We currently don't use the Tomcat Manager.

Now, i can't have my config be a part of my war anymore. It needs to instead sit on the server in a persistent way (=externalized config). Tomcat seems to make this basically impossible for me. I am now using for my config. In the context, i have a JNDI environment entry that specifies where the workspace folder for this app (which includes config files etc.) is located. I can not hardcode this in my war, because the same war is used for development, production and staging, and the workspace location is different for all of those.

This external context XML works fine, until Tomcat deletes it. If see basically no way, without the manager, to redeploy my war without this file getting deleted. I can't restart the server (our admin does that) and i don't see why i should be forced to shut down the server just to prevent tomcat from deleting my configuration when i delete the old war. This Tomcat behaviour doesn't make any sense for me.

- Some people have suggested to make the config read-only. This doesn't work, because tomcat will not autoDeploy a new war if it cannot delete the config.
- Some people suggest not using autoDeploy. As explained, this would require me to restart tomcat on every deploy or use the manager.

So, what i would like to get more information on:
Do i HAVE to use the manager? Or am i just stupid?
And is the manager capable of deploying a new war without deleting my context?
And why is this stupid behaviour still a thing? I have seen tons of posts of people with this problem, here, on stackoverflow, on the mailing lists. It creates problems for everyone it seems, and i have not seen a proper solution that applies to my situation.
10 months ago