hey @jreedmoore the issue with those tends to center around the fact that both spring and aspectj go through a bunch of initialization and instance rewiring that isn't directly visible from the usual repl engagement model, which centers around importing classes on the classpath and then instantiating them. You need to be able to get into the instance graph after all the wiring is done. Do you have a way to do that?

oh so I would need to hook into the Spring machinery to pull out an instance of one of these classes?

there's some like applicationContext.get<blah>Bean method that lets me get singletons right

ugh I am so sorry for other people reading this, it's all very anti-simple

yes- it's been some years but asking a global application context for a named bean rings a bell.

yeah so. I have buy in from my manager to potentially rip this subsystem into a separate jar. I think I'm going to do that rather than beat my head against Spring all week

other approachs I've seen while googling around are basically put another Bean in your application context + object graph that starts up an nREPL and sets a var in user to the application context

yeah- you do need a way to start up an nrepl server, and in a spring app that has to be wired into spring

but once you connect to the repl, you should be able to import the applicationcontext singleton class, and then get the beans from it

hi, imagine some state (currently an atom) that’s updated by http POSTs. there’s a chance that more than one request will come in at roughly the same time (within a few seconds), but i only want the first one to update the state and ignore the others - any idea on how to do that?

hey @sd presumably prior to the POSTs clients are issuing GETs regarding the resource in question? In that case, an approach to solve for first-one-in-wins is to keep a token, like a UUID, as part of the atom-maintained state and deliver that token to clients in the GET responses. Clients are to return the token with their POSTs. When you receive the POST, compare the received token with the one in the atom, and ignore the POST if the token doesn't match. If it does match, create a new token and include it in the state change of the atom.

@sd I would add an :updated keyword to the atom and use that as a guard. As long as it is false, you can update the atom, if it is true, you cannot. That will also give you the option to set it to false again some time later.

gotcha. so something like (if (= current-token token-from-request) (do (swap! …))

basically, this is for an online game where there are two teams, and multiple players on each team (but i only want to accept answers from one player at a time). I will probably keep something like :current-team in the atom and use that for the check

i was thinking that i might need to a ref with the conditional update inside a dosync but it’ll be less work to stick with an atom

yup- if the moves on each turn are state dependent, then you probably want a token scheme, but if the moves are stateless, then a :current-team should be enough

thanks

hey what backend stack do you guys recommend to get started with in clojure?

I know that ring seems to be the main thing people use to abstract away http requests and responses

but what other common libraries should I look into