Clojurians Log v2

hi there - I am getting lost in the forest of wildfly documentation. At the moment my JDBC driver pulls environment variables using env rather than using JNDI resources. What’s the quickest and secondly the idiomatic way :simple_smile: to pass in deployment specific properties to an immutant WAR in wildfly?

and thanks!

so one answer is to pass in —properties=/my/path/to/app.properties when calling bin/standalone.sh (but it seems it must be fully qualified)

hi colin. we usually recommend the environ lib for app config, even when deployed to WF

but if you're dealing with a JDBC datasource configured in standalone.xml, that may be trickier

so what exactly are you configuring? :simple_smile:

and keep in mind that "quickest" and "idiomatic" are often at odds on wildfly :simple_smile:

yes, I am learning that :simple_smile:

So I typically build up a datasource compatible map pulling in the parameters using env

e.g. (goes to find one…)

(def prod-spec "The production database envionrment" {:subprotocol "jtds:sqlserver" :subname (str "//" (env/env :health-db-server) ":" 1433 "/" (env/env :health-db-name)) :user (env/env :health-db-user) :password (env/env :health-db-password)})

at the moment when I do ‘lein run’ I simply pass them in as system variables

putting those properties into a .properties file and launching bin/standalone.sh —properties=that-file.properties makes it work

but that feels hacky...

well, hacky is a state of mind. the "idiomatic" way would be more like this:

(def db-spec {:factory immutant.transactions.jdbc/factory :name "java:jboss/datasources/ExampleDS"})

but that pushes all the config into your standalone.xml

also hacky

ah OK. I don’t feel too bad then.

i will say, colin, that same process (passing --properties) should work for configuring both places (your app or standalone.xml) since you can refer to properties in standalone.xml

there are some tradeoffs there

downside is you have to maintain your own standalone.xml, which is kind of a pain when upgrading your wildfly version

upside is your datasource can then participate in a distributed transaction, but that may not be worth anything to you

good to know. For me it is about lightweight deployment so the properties file is probably the way to go

@colin.yates: i'm curious why you're deploying to wildfly then. is it only to facilitate deployment on windows (i saw your ML post)?

good question. That is certainly the main reason and I am just about to start including things like quartz, possibly caching further down the line and a few people whose opinion I respect are choosing wildfly over http-kit.

My reason for http-kit is for sente - whether I still use that or the immutant websockets support is TBD

at some point I got fed up with chasing libraries and a curated set wins. (don’t get me started on #C099W16KZ roll your own or #prelude :-)).

If you use http-kit, are you going to do so from the war file deployed to WildFly?

if so, you'll have to run http-kit on another port, which would be a bit weird

@tcrawley: no, I am going to undertow via wildfly

good call :)

my migration was: sente rocks -> http-kit -> windows then a whole bunch of yak health care maintenance, realisation there must be better things in life and Immutant

@colin.yates: funny you mention quartz since it's not provided by wildfly. it's the immutant.scheduling lib that pulls that in, so it works the same in or out of a container.

yes, exactly. At some point I realised that Immutant was where I was heading anyway so why do it myself? Wildfly is really a means to an end for me.

@colin.yates: doesn't new sente support immutant too though? At least if that's your reason for keeping http-kit.

it does but I have no preference for http-kit.

it might be worthwhile to research "deploying clojure jars as windows services" solutions before committing to wildfly, if windows is the only reason you're looking at it. or maybe just replicate its bin/standalone.bat script for your jar? (i know bupkis about windows services)

I seem to have given the impression of some allegiance towards http-kit - it is great and all, but it is a means to an end

I know slightly more than bupkis as well but enough to know it is painful. I also want (as close to a) single deployment approach and wildfly gives me that across the macs, linuxes and windows

What I've meant if the only reason you're using http-kit is sente, then since sente 1.4.0 there's no reason to anymore - you can use it with immutant no problem.

@jaen - yep, we are on the same page :simple_smile:

Ah, gotcha, I must have misunderstood you, I parsed it as "I'm keeping http-kit because sente doesn't support immutant" for some reasone. My bad then.

urk, I just realised my message was ambiguous: "my migration was: sente rocks -> http-kit -> windows then a whole bunch of yak health care maintenance, realisation there must be better things in life and Immutant” should have ended “better things in life and Immutant was the answer"

@jaen, I seem unable to type today - I almost certainly led you down the wrong path :simple_smile:

Hah, happens. Luckily no one was seriously injured ; d

you know those days when the best thing for the project is to stay in bed….