Building Your Own JBoss Configuration - Unpacking JBoss and Initial Startup

Unpacking JBoss and Initial Startup

This section will provide a quick walk-through of unpacking and launching JBoss. If you've done any work with JBoss you will want to jump to the next section immediately.

Running JBoss under any Unix-like system (I use both Mac OS X and Linux) is rather trivial, although there is one issue about file permissions I'll mention in a moment. JBoss under Windows NT/2000/XP is also pretty easy, although the approach is just slightly different. Unlike Unix programs that place files all over the file structure, JBoss sits in one single directory—with several subdirectories of course. You can even unpack JBoss in your own home directory and run it from there. (A good option for simple initial testing, although for a real production or development deployment you'll want to plan its eventual location somewhere more appropriate.)

My point is that it really doesn't matter [to me] where you unpack JBoss. If you have a Linux system, you might choose /opt/jboss or /usr/local/jboss. Apple placed an early version of JBoss in their OS X 10.3 Panther install CDs¹ that installed to /Library/JBoss. My suggestion is this: create a /usr/local/jboss (or maybe /Library/JBoss for OS X) directory, and then unpack different versions of JBoss to different subdirectories. For example, I've got JBoss versions 3.2.3, 3.2.5 and 4.0.0 installed on my computer. Their root directories are /Library/JBoss/3.2.3, /Library/JBoss/3.2.5 and /Library/JBoss/4.0.0 respectively. I also created a symlink at /LibraryJBoss/current that points to the version I'm most actively using. This is a good idea because you will want to carefully test your application on a new version of JBoss before moving everything over, just in case some new feature breaks your existing code.

Finally, there's an issue about permissions. JBoss will need to read all of its subdirectories, and it will need to be able to write to files in some specific subdirectories. If you are the only user of your computer system and you unpacked the files under your own user account (so you are the owner of all files and directories) you shouldn't have a problem. The smarter way to install files on a multi-user system (or a production server) is to create a "jboss" group², change group ownership of all JBoss files and directories to the "jboss" group, and add yourself to that group. It is also vitally important that you change the access permissions so that the "jboss" group has write permissions. (If you want to be uber-cautious, you would only change the permissions of each server configurations' tmp, work, data and deploy subdirectories leaving conf and lib to be only changed by the owner. I just open group permissions to all the subdirectories.)

Here's an example, once you've created the JBoss group, of how I would unpack things. Here I'll assume I'm unpacking everything in Linux. (The stuff behind the # are comments.)

mkdir /usr/local/jboss
cd /usr/local/jboss
tar xjf ~/jboss-4.0.0.tar.bz2   # assuming the archive is in your home directory
mv jboss-4.0.0 4.0.0            # I like to rename the directory to make it shorter
chgrp -R jboss 4.0.0            # change group ownership to "jboss"
chmod -R g+w 4.0.0              # give group write access
ln -sf 4.0.0 current            # create symlink

I've got many versions of JBoss simultaneously installed. On my system things look like this:

julius:~ murray$ cd /Library/JBoss/
julius/Library/JBoss murray$ ls
3.2             3.2.5           4.0.0DR4        current
3.2.3           4.0.0           4.0.0RC1
julius:/Library/JBoss murray$

Once again: these steps are not necessary if you just want to try JBoss out quickly. You could unpack everything in your home directory, change into that directory, and proceed to the next step. The above are for if you want to do a more robust installation. Also note that this doesn't apply to Windows. For that, just unpack JBoss wherever you want. Figuring out more careful file access security is up to you.

All that's left is to start the JBoss server. You can do this by executing bin/run.sh (or run.bat in Windows). You should see a bunch of messages flying by, but nothing should look like a Java error stack trace. The only errors I've seen at this point had to do with JBoss being unable to create its own log files and temporary files. (Meaning, you didn't do the careful file permissions work I'd mentioned above!)

Note that there are two ways to shutdown the server. The first way is to hit Control-C on your keyboard. The other way is to open another terminal window and execute bin/shutdown.sh -S.

There's your quite primer on getting JBoss up and running. If you've found an error or imporant caveat to these notes, feel free to let me know. If your computer isn't working and you want help figuring it out, don't bother e-mailing me. I don't mean to be rude, but I don't have time to play "help desk" to millions of people on the Internet. (Or if you insist, my rate is $100 per hour, 1 hour minimum.) Now that's out of the way, we can start looking at server configurations.

1. It doesn't install by default, but you could look for it if you wanted. (I think it's on the XCode CD somewhere.) That version (3.2) is now a little outdated. There was something done with Apple's XCode so that you could design and deploy an EJB application to the JBoss server automatically, but it's really not that important.

2. Creating a group on OS X is beyond the scope of this article. To do it right you (a) take a couple Asprin or fix yourself a stiff drink and (b) figure out how the Netinfo manager (located in the Utiltiies folder which is in the Applications folder) works. You could also use the Accounts pane under the System Preferences to create a "JBoss" account, which would then get its own group. But that's a waste because you don't need the accompaning user directory and all the other cruft.

Next section: JBoss server configurations

Page last modified 10/29/2004 15:02