This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-09-21
Channels
- # admin-announcements (17)
- # aws (19)
- # beginners (28)
- # boot (103)
- # cider (5)
- # clojure (183)
- # clojure-art (46)
- # clojure-russia (25)
- # clojure-sg (2)
- # clojure-uk (1)
- # clojurescript (342)
- # clojurex (3)
- # core-matrix (1)
- # cursive (1)
- # datascript (2)
- # devcards (77)
- # devops (15)
- # emacs (4)
- # funcool (8)
- # hoplon (15)
- # immutant (47)
- # jobs (1)
- # ldnclj (10)
- # lein-figwheel (4)
- # off-topic (2)
- # om (23)
- # onyx (10)
- # re-frame (1)
- # reagent (23)
- # yada (7)
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 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?
and keep in mind that "quickest" and "idiomatic" are often at odds on wildfly
yes, I am learning that
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 :-)).
@tcrawley: no, I am going to undertow via wildfly
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
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
you know those days when the best thing for the project is to stay in bed….