Fork me on GitHub
#immutant
<
2015-09-21
>
colin.yates11:09:51

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?

colin.yates11:09:15

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)

jcrossley313:09:13

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

jcrossley313:09:46

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

jcrossley313:09:05

so what exactly are you configuring? simple_smile

jcrossley313:09:59

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

colin.yates13:09:06

yes, I am learning that simple_smile

colin.yates13:09:31

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

colin.yates13:09:37

e.g. (goes to find one…)

colin.yates13:09:32

(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)})

colin.yates13:09:55

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

colin.yates13:09:46

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

colin.yates13:09:57

but that feels hacky...

jcrossley313:09:35

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

jcrossley313:09:39

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

jcrossley313:09:53

but that pushes all the config into your standalone.xml

colin.yates13:09:32

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

jcrossley313:09:53

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

jcrossley313:09:08

there are some tradeoffs there

jcrossley313:09:50

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

jcrossley313:09:20

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

colin.yates13:09:36

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

jcrossley313:09:16

@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)?

colin.yates13:09:17

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.

colin.yates13:09:51

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

colin.yates13:09:23

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 :-)).

tcrawley13:09:41

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

tcrawley13:09:04

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

colin.yates13:09:04

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

tcrawley13:09:13

good call :)

colin.yates13:09:53

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

jcrossley313:09:57

@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.

colin.yates13:09:32

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.

jaen14:09:04

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

colin.yates14:09:28

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

jcrossley314:09:44

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)

colin.yates14:09:03

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

colin.yates14:09:57

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

jaen14:09:36

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.

colin.yates14:09:48

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

jaen14:09:30

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.

colin.yates14:09:39

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"

colin.yates14:09:56

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

jaen14:09:23

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

colin.yates14:09:32

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