JBoss 7 – Ho Hum or Something to Get Excited About?

I never even got a chance to play around with JBoss AS 6 and here is release 7. Are app servers in a race with web browsers for who can get the highest number? Ha – well probably not, but enough of this – what’s in this release and why should anyone care? I’ll pick through the most obvious things and also run thru how to get the product setup for use on my trusty windows laptop. If I get a chance I’ll install the latest fedora inside virtual box and check it out there too.

The main release page for the new app server sure sounds amazing – “blazing”, “elegant”, “extreme performance”, wow that’s some billing to live up to. When I look at my use of jboss over the years here are some things that I’ve always found challenging:

  • Memory: jboss has always required a ton of memory and the whole permgen and running out of memory has been a pain even with stuff from jboss (the portal for example).
  • Startup time: depending on what you are doing it can take quite a bit of time to cycle the app server.
  • Administration: the admin site is a befuddling mix of pages to dig around in to find useful things.
  • Application deployment status: figuring out if your app actually deployed or not has always required a stroll thru the log file rather than some kind of simple status in the admin tool. I shouldn’t have to troll a log file to know if my jbdc pool deployed ok or not.

With those in mind its off to work – and of course with 8 years of jboss under my belt there’s no change I’m RTFM’ing this  – I’m on vacation after all 🙂 I grabbed the full installer package from the site and extracted it to this path on my machine: C:dev_toolsjboss-as-7.0.0, opened a command prompt, went to the bin, and executed run.bat. Crap…ok things are different. The files in the bin have been changed up a bit. If you have other jboss app servers installed (I have 4 and 5) you may need to add a line to reset your jobss home directory. There are several startup files in the bin. I picked standalone.bat as the most likely replacement for run.bat. It has a couple of companion config files – I added a line to standalone.conf.bat: SET JBOSS_HOME=C:dev_toolsjboss-as-7.0.0 and then ran standalone.bat – viola! 12 seconds later jboss is up and running. Cycling the server and on the second startup it took 1973ms to get back up and running. Ok that’s pretty impressive, but there’s nothing being deployed remember. On the memory side I see about 90MB being used at startup. After loggin into the admin console and poking around memory usage rises to 107MB of RAM. That’s not too bad considering firefox is consuming 538MB as I write this post.

So with that out of the way, the deployment directory structure has received similar tweaks. War files and other deployables need to be placed in the standalonedeployments directory. The scanner works a bit differently. I have some war files that I’ll try to quickly deploy – the first is a totally stripped down and exploded war. I drop the folder into the directory and then you need to add a file to tell the scanner what to do (that’s new). My war folder is “beren.war” and I need a plain empty text file “beren.war.dodeploy” is placed in the deployments folder. Every time jboss finds an error during deployment it will change the extension to “failed”. You then go fix the issue and change the name back and try again. Success leaves the file with a “deployed” extension. That’s a little annoying, but it does seem to get the container to reload the war file easily. My war seems to deploy ok, and after placing MySQL jars in the server’s lib directory I can connect to a MySQL db using a straight JDBC connection.

Creating a simple datasource was not quite so simple, but I did find a good page here. It is a bit confusing in that there are a couple of ways to deploy a datasource and I think the documentation is not 100% clear what is the best way. I used the domain approach and deployed the datasource at the app server domain level – in my case “standalone”. To do this I put the MySQL jar file “mysql-connector-java-5.1.15.jar” into the deployments directory “C:dev_toolsjboss-as-7.0.0standalonedeployments” and then edited the standalone.xml file adding my datasource to the datasource section:

<datasource jndi-name="java:/TestDB" pool-name="TestDB_Pool" enabled="true" jta="true" use-java-context="true" use-ccm="true">

Then you’ll need to add a new entry to the drivers section like this:

<driver name=”mysql-connector-java-5.1.15.jar” module=”com.mysql”/>

Once that is done you should be off and running with the basics.You can do and monitor all these things in the new console app too. The verdict is still out on the console, but definitely the new GUI is  a welcome addition and brings JBoss a bit closer to weblogic/websphere for gui administration.

After getting these things configured jboss is still starting up reasonably quick with not too much more RAM consumed. My next task will be to see what happens when I run the portal and then load it up with a bunch of concurrent users with JMeter. JBoss 7 definitely seems like a must have  so far. Performance definitely rocks. I’d have to say the memory usage so far looks good and it sure seems like there’s a definite improvement in the admin console. That’s 3 out of 4 things – yes deployment is still a murky issue – but all in all JBoss 7 looks pretty darn nice.

2 Responses

  1. lukasw44 says:

    Hello i do it as you say and i have got error in jboss:
    New missing/unsatisfied dependencies:
    service jboss.jdbc-driver.mysql (missing)

  2. Beren says:

    Did you place a copy of the mysql connector-j jar files in the server lib directory?

Leave a Reply