To deploy an Immutant application to WildFly, you'll need to generate
a war file via the lein immutant war
task.
The task's behavior can be configured with the following options under
the [:immutant :war]
path in project.clj
, all of which can be
overridden via command line switches.
:context-path
- The context path to attach the application to. By
default, the application will use a context based on the name of the
war file, so a war file named foo.war
will be hosted under /foo
.
To override that set :context-path
to the desired context. If you
want the root ('/') context, you can either set :context-path
to
"/" or name the war file ROOT.war
.
This value is written to WEB-INF/jboss-web.xml
inside the war, and
a copy of the file is written to :target-path
.
The context path can be specified on the command line as -c CONTEXT
or --context-path CONTEXT
.
:destination
- The directory where the war file should be placed.
To ease deployment to WildFly, you can specify the root of your
WildFly installation and the archive will be placed within the
standalone/deployments/
directory under that root instead of at
the root. Defaults to :target-path
.
The destination can be specified on the command line as -o DIR
or
--destination DIR
.
:dev?
- Tells the task to create a development war with the
following characteristics:
~/.m2/
.:repl-options
from your
project.clj
applied.The development war allows the ring.middleware.reload
middleware
to reload changed namespaces on disk, and doesn't require you to
regenerate the war file after making source changes. You will still
need to redeploy the application to see any changes that the reload
middleware can't load, and you'll need to regenerate the war if you
change any dependencies in project.clj
.
Defaults to false
, which results in an uberwar containing all of
the application's code, resources, and dependencies.
Development mode can be specified on the command line as -d
or
--dev
, or disabled with --no-dev
.
:name
- Specifies the name of the war file (without the .war
suffix). Defaults to %p%t
, and supports placeholders:
%p
for the project name%v
for project version%t
for the type suffix (which will be -dev for dev wars, ""
for full wars).The name can be specified on the command line as -n NAME
or
--name NAME
.
:nrepl
- A map that specifies the options for an nREPL endpoint.
:host
- The host to bind to. Defaults to "localhost".
Can be overridden on the command line via --nrepl-host HOST
.:port
- The port to bind to. Defaults to 0
, which means a
random port. Can be overridden on the command line via
--nrepl-port PORT
.:port-file
- The file where the nREPL port is written for
tooling to pick up. Can be relative to the app root or absolute,
and must be absolute when used with an uberwar. Defaults to both
.nrepl-port
and :target-path/nrepl-port
, which is the same
as lein's default. Note that when specifying a port file, you can
only specify a single file. Can be overridden on the command line
via --nrepl-port-file FILE
.:start?
- Controls if an nREPL endpoint is started or not. For
development wars, this is true
by default, false otherwise. Can
be overridden on the command line via --nrepl-start
, or disabled
with --no-nrepl-start
.:resource-paths
- A vector of directories containing resources
that need to be copied to the top-level of the war file. These
directories are different than the lein-standard :resource-paths, as
those will be included in the war automatically. These directories
are used to override or add configuration to WEB-INF/
or
META-INF/
dirrectories within the war. Can be overridden on the
command line via -r PATH1,PATH2
or --resource-paths PATH1,PATH2
.
:virtual-host
- The name of a host defined in the WildFly
configuration that has virtual aliases assigned. This likely won't
be the actual hostname. See the
WildFly docs
for more detail.
This value is written to WEB-INF/jboss-web.xml
inside the war, and
a copy of the file is written to :target-path
.
The host can be specified on the command line as -v HOST
or --virtual-host HOST
.
(project my-app "0.1.0"
...
:immutant {
:war {
;; the following will generate foo-0.1.0.war, or
;; foo-0.1.0-dev.war for dev wars.
:name "foo-%v%t"
;; Destination defaults to :target-path
:destination "path/for/war/"
;; contents placed at the top-level of the jar, useful for
;; overriding WEB-INF/web.xml, etc. If, after copying these resources,
;; we don't have a web.xml, we'll add our own.
:resource-paths ["war-resources"]
:context-path "/"
;; not a hostname, but the name of a server configuration
;; in the WildFly xml
:virtual-host "some-configured-host"
;; override the nREPL settings
:nrepl {:host "0.0.0.0"
:port 1234
:port-file "path/to/port/file"
:start? true}}}
:main my-app.core
...
)
When generating an uberwar, we generate an uberjar using the standard lein uberjar task, so all of the options for the uberjar task are applied.
For both developer and uber wars, we generate a WEB-INF/web.xml
that
acts as an entry point in to your application. As a convenience, we
drop a copy of that web.xml
in to :target-path
in case you need to
modify it. You'll want to place your copy in a directory in your
application root and point [:immutant :war :resource-paths]
at it so
it will get picked up. We also generate a
WEB-INF/jboss-deployment-structure.xml
that specifies what WildFly
modules the application depends on, and drop a copy in
:target-path
. We do the same for WEB-INF/jboss-web.xml
if you
specify a :context-path
or :virtual-host
.
For both types of war archives, you'll need to specify a :main
as
the entry point for your application.
Can you improve this documentation?Edit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close