“Good servers do not save bad habits. JBoss just makes it easier to see which habits to fix.”
Why JBoss clicks for product teams
The last few months I have been helping teams move to JBoss AS 7 and EAP 6. The draw is simple. Fast startup. Clean modules. A management story that does not fight you. People come from Tomcat and from heavier suites and find that JBoss feels closer to how we build apps today. You get first class CLI, clear profiles, and sane defaults.
That said, a server is only as friendly as your setup. If your config lives in emails and your war files carry secrets, you will still lose time. The goal here is a practical path that gets a repeatable JBoss setup for a real team. Nothing fancy. Things that survive on call nights and new hires.
What went wrong before we fixed it
We started with a couple of dev boxes that had been tweaked by hand. One ran in standalone, the other in domain. One had the JDBC jar inside the app, the other under modules. Logs were rotated by cron on one box and by the server on the next. When a bug hit, nobody knew which box had which change. Classic drift.
We drew a simple line. Configs in version control. Binaries from a known build. Drivers as modules. Datasources managed by the server. Users and secrets kept out of the app. The fixes were boring, which is why they worked.
Deep dive 1. Standalone or domain and the CLI
Pick one mode and commit to it per environment. For most teams, standalone is the right start. It is simple to reason about and still gives you profiles and subsystems. If you have many servers and need shared management, domain brings host controllers and server groups that keep config in one place.
The real win is the JBoss CLI. Treat it like your scriptable admin. Store CLI commands in your repo and run them in your deploy job. Create datasources, tweak thread pools, set log levels, and keep the commands next to your app code. This gives you repeatable setups and a clear history of changes. No more guessing what someone clicked last week.
Deep dive 2. Datasources, drivers, and security that age well
Put the JDBC driver as a module. That keeps jars out of your wars and lets many apps share one driver. Reference the module from your datasource and keep the datasource managed by the server. This avoids classloader surprises and makes upgrades easier.
On security, split management users from application users. Use the provided add user tooling for ops accounts and wire app auth through JAAS to your directory, whether that is LDAP or Active Directory. For secrets, use the JBoss Vault so passwords do not sit in plain text inside config files. When you promote builds, swap only the vault data and environment specifics, not code.
SSL is still common at Apache httpd, and that is fine. If you front the cluster with httpd, terminate SSL there and talk AJP or HTTP to JBoss. Keep cert rotation a single step in your web tier and your app tier stays clean.
Deep dive 3. Clustering, sessions, and sane tuning
If you need high availability, start with mod_cluster. It lets JBoss tell Apache exactly what is running and when a node is too busy. Use sticky sessions for most apps. If you must share sessions, JBoss uses Infinispan for web session replication and it is fast enough for many cases, but measure before turning it on everywhere.
Messaging works out of the box with HornetQ. Keep it on the same box for lower latency unless you know you need a separate broker. For logs, use the built in rotation and keep WARN and ERROR quiet enough that alerts mean something. On the JVM side, set a fixed heap and pick a collector that matches your traffic. Keep GC logs on so the day you need them, they are already there.
A reflective close for teams that ship
What makes JBoss shine is not a hidden feature. It is the way it lets you keep your stuff tidy. Put config in git. Script your CLI steps. Keep drivers and secrets where they belong. Front with Apache when it helps. Start simple, then add clustering only where it pays off. These are boring moves, and they make a stack that survives crunch time. That is the kind of setup you can hand to a teammate and feel good about.