Migrating from TorqueBox 3 to TorqueBox 4
NOTE: This guide is still largely a work-in-progress and missing quite a bit of content. Until TorqueBox 4 gets out of alpha, only attempt migrating TorqueBox 3 applications if they are relatively simple (mostly web) or you’re prepared to dig into the API docs and source to see what’s changed. If you do attempt to migrate your application, please provide us feedback so we can update the guide.
TorqueBox 4 is quite different from TorqueBox 3 in several ways, the largest being:
- An Application Server is no longer required. TorqueBox 4 ships as a collection of gems, and can be used in a standalone JRuby application - you no longer are required to download and manage a monolithic container. Even though the container isn’t required, you can still deploy TorqueBox 4 to a WildFly server to take advantage of clustering, load-balancing, and failover features. For more details on using WildFly, see our WildFly Guide. For details on gem usage, see our Installation Guilde.
- Applications can now be packaged as executable jar files. TorqueBox 4 supports packaging your entire application (including gems and JRuby itself) as a executable jar file that can run anywhere Java is available without any other dependencies. For more details, see our Jar Guide.
- Everything is started/configured dynamically. In TorqueBox 3,
the majority of your application’s resource setup was static, and
had to be in
torquebox.rb. In TorqueBox 4, all resources can be set up dynamically, at runtime (more on this below).
In TorqueBox 3, most of your resources had to be set up statically at
deploy time, either through
TorqueBox 4, neither of those files are supported, and you instead set
up resources at runtime from within your application code.
Features missing or removed since TorqueBox 3
- TorqueBox::Messaging::Backgroundable and related APIs
- stomp and stomplets
- distributed transactions (XA)
- services / long-running daemons
- pooled JRuby runtimes - all Ruby code is expected to be thread-safe and run in a single runtime
Some of these may come back in some form or other, depending on our user’s wants and needs. TorqueBox 4 is still in the early stages and under heavy development.
Message Processors -> listen
Synchronous Message Processors -> respond
- queue enumeration
- no job classes, just blocks
- no job timeouts (yet)
- no passing configuration to jobs