Forum: JRuby Why .war files?

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
974b3d592f78510db0227e528841ccb9?d=identicon&s=25 Robin McKay (robin2)
on 2012-06-24 17:21
I'm new to JRuby and maybe I'm missing something that's blindingly
obvious to everyone else.

I can understand that there are corporate situations where a JRuby/Rails
developer has no option but to package their product into a .war file
and hand it over to the people that administer the webservers.

But someone developing their own product isn't obliged to comply with
any corporate edict about how a webserver is run and I can't see why you
would bother with packaging things into a .war file. It seems it would
be much easier to include, say, Trinidad or Mizuno in your application
and just copy the entire application onto the server - assuming the
server is running the JVM.

Is there some advantage to .war files that I don't understand and which
justifies the extra complexity?
666badca71c452ae51c999971419b506?d=identicon&s=25 Joe Kutner (Guest)
on 2012-06-24 17:36
(Received via mailing list)
There are a few advantages to using a WAR file instead of a directory of
loose files:

1) Security - a WAR can be signed to ensure that it has not been
tampered with or corrupted along the way. If it has, the server won't
deploy it.
2) Consistency - you can package all of your apps dependencies into to a
WAR. This eliminates the need to run `bundle install` at deployment
time, which is slow and sometimes unreliable.
3) Portability - deploying a WAR file is pretty much the same on
Windows, Linux, etc. (more so than a capistrano deployment).
4) Speed - WAR file deployments are typically faster than capistrano for
a number of reasons (including #2 above).
5) Privacy - you can compile your ruby code into byte code inside of a
WAR file to obfuscate it (useful if you are deploying to untrusted

But there are disadvantages too:

1) Making your development environment match your production environment
is difficult (because you don't want to regenerate a WAR file after
every code change).
2) Warbler doesn't provide any extensions like Trinidad does for
scheduled jobs, resque, etc. It really just handles the web part.

I go into more detail about this in my book, "Deploying with JRuby":

I also discuss TorqueBox Knob files, which provide many of the same
advantages as WAR files.

1273e5c266e0c4cc4065fff3a6fe7056?d=identicon&s=25 Anthony Juckel (Guest)
on 2012-06-24 17:39
(Received via mailing list)
Aside from the fact that they're self-contained (a single file to copy,
rather than a whole directory tree), not really.  If you don't have an
entrenched Java app server, and are comfortable with Ruby-style
Torquebox or Trinidad are likely preferable to using something like
F472b397918df02e70d8d7d0cf086c00?d=identicon&s=25 Dick Davies (Guest)
on 2012-06-25 11:38
(Received via mailing list)
All the deps. are bundled in, it's just a cleaner way of keeping things
together in my experience. Bundle in a Jetty or something (pretty sure
Warbler supports that now) and you don't need anything else.
27598e1b77ce41fb0bd8a6fc4a3715d4?d=identicon&s=25 Patrick Mahoney (Guest)
on 2012-06-25 17:19
(Received via mailing list)
On Sun, Jun 24, 2012 at 10:36:16AM -0500, Joe Kutner wrote:
> 2) Consistency - you can package all of your apps dependencies into to a WAR.
> This eliminates the need to run `bundle install` at deployment time, which is
> slow and sometimes unreliable.
> 4) Speed - WAR file deployments are typically faster than capistrano for a
> number of reasons (including #2 above).

Hm, this is the opposite of my experience.  I wonder if I am doing

With Capistrano, I can do an incremental source-code update, then
Unicorn (or whatever). On my ci server, the common case is that no
have changed, so bundle install is minimal.

With Warbler/Glassfish, building the 100MB WAR file (Rails app with fair
of deps) takes a good minute or so, and deploying takes even longer.

I have yet to dig into what parts take how long; there are actions that
Glassfish takes before invoking any of my code, and actions
take to initialize.

What sort of WAR file size are you typically dealing with?  Was there
specific you did to get things to go fast?  One thought I had is that
does not set '<webapp metadata-complete="true" ...>' in web.xml, but I
only expect a minor speed up after that.

666badca71c452ae51c999971419b506?d=identicon&s=25 Joe Kutner (Guest)
on 2012-06-25 17:47
(Received via mailing list)
Yea, if the code changes are small and there are no dependency changes,
I suppose Capistrano is the winner.  I've typically used a CI server to
generate the WAR file continuously, so I wasn't including the cost of
building the artifact and putting the deps in it.  My WARs are ready to
go when I "push the button".

So let me clarify my claim of speed:
- transfer of app code and dependencies (the whole app) to the
production can be faster.
- hot deployment of a WAR file can be faster than restarting a bunch of
processes with Unicorn or passenger - assuming you have more than one :)

I should probably take two apps that are identical and run on JRuby and
MRI and benchmark their respective deployments.  Would be interesting.
974b3d592f78510db0227e528841ccb9?d=identicon&s=25 Robin McKay (robin2)
on 2012-06-26 17:39
Thanks for all the helpful information. I guess it has largely confirmed
what I suspected.

I have been experimenting with including a copy of JRuby (not just the
.war) in my app which means that all of the gems for that app are
automatically included and can't be confused with the gems for any other
app. Then if I put the entire app (including JRuby) in a .zip or .tar.gz
it can be easily copied anywhere with no external dependencies and when
extracted it behaves just like on the development PC. If I include a
shell script or batch file it can be started with a double-click. If
it's a Rails app and I include Mizuno then it will run anywhere the JVM

The .zip or .tar.gz is no bigger than the .war version of JRuby and
there are no complications about including gems - which is more
difficult with the jruby.war.

And when I do it this way there seems to be no advantage to using RVM
is great for MRI Ruby) or Bundler which does things that I don't
expect and has very inadequate documentation.
This topic is locked and can not be replied to.