I was recently tasked with installing JBoss 4.2 on Centos/RHEL 5. I found the experience remarkably difficult, so I figured I should share it for my own future reference, and hopefully to also save the sanity of whatever other poor souls are tasked with the same project.
- Start off with RHEL 5 or Centos 5
- Install jpackage50.repo into /etc/yum.repos.d/ (instructions for how to make this file can be found at jpackage.org)
- run “yum update”
- run “yum install jbossas”
- If you see this message: ” –> Missing Dependency: /usr/bin/rebuild-security-providers” then download jpackage-utils-compat-el5-0.0.1-1.noarch and install it by using rpm -i jpackage-utils-compat-el5-0.0.1-1.noarch.rpm , then run “yum install jbossas” again. See this bug at Red Hat for details, and http://www.zarb.org/pipermail/jpackage-discuss/2008-July/012751.html for how the rpm was built.
- run “/sbin/chkconfig jbossas on” to start JBoss automatically at startup
- Until this bug is resolved , run this command: “ln -s /usr/share/java/eclipse-ecj.jar /usr/share/java/ecj.jar”
- If you want JBoss to listen to requests from systems other than localhost, edit /etc/jbossas/jbossas.conf. Create a new line that reads “JBOSS_IP=0.0.0.0”.
- put your .ear’s, .war’s, ejb .jar’s, *-ds.xml’s into /var/lib/jbossas/server/default/deploy
- Start JBoss by running “/etc/init.d/jbossas start”
JVM args can be found in /etc/jbossas/run.conf.
Note that if your web application (war, ear, whatever) depends on JNDI, you need to edit /var/lib/jbossas/server/default/deploy/jboss-web.deployer/META-INF/jboss-service.xml and a line for each JNDI data source like this: “<depends>jboss.jca:service=DataSourceBinding,name=jdbc/whatever</depends>”. This little detail cost me quite a few hours to figure out… an explanation as to why this is necessary can be found at http://confluence.atlassian.com/display/DOC/Known+Issues+for+JBoss. Basically, JBoss will start applications before JNDI data sources unless told otherwise, so your application will error out on startup with an exception like this: “Caused by: javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.NameNotFoundException: jdbc not bound]”.
Some may argue that I should have simply downloaded the tar from jboss.org and manually installed JBoss without a package manager. However, the package manager offers a lot of advantages, such as dependency resolution/management, automatic updates for security and/or new features, clean and easy uninstall, and a lot more. When given the choice, I always choose to use a package manager, and will even create packages if ones are not available, and I report package bugs so others, and my future self,will have a better experience.
A lot of the pain in installing JBoss is due to bugs in the packaging. I hope that jpackage.org / Red Hat solves these problems soon – I wouldn’t really want anyone to have to live through the trouble I went through to figure all this out again.
Install JBoss 4.2 on Centos/RHEL 5 by Craig Andrews is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Excellent post and very well argued.
Let’s hypothesize for a moment. Let’s say that JBoss engineers are i) busy working on the next release or something, ii) are not hearing from their customers in overwhelming numbers that packaging matters, and iii) maybe that is partially due to having an ear tuned mostly to developers who tend to care less about the advantages of package management.
(BTW, the above situation describes the early Fedora Core days when it was time to work on a RHEL release. It was from this situation that Fedora Extras was born, and that changed the game forever. What is the equivalent ‘JBoss Extras’ here?)
What if people in a similar situation as yours were to speak up and say, “Here, we’ll do that for you.”
Granted, it’s not going to be easy, nor necessarily possible with all JBoss projects/products. The binary JAR compiled with another binary JAR is a bit of a rabbit warren to chase through. Changes may be required in core projects that are hard to bring about. But there are various grassroots efforts, home-baked packages, and so on where other people are working on this. We’ve had some push on it from the Fedora ISV special interest group[1].
From a community angle, I see the work is two-fold:
1. Some person or group needs to lead the effort, from a project management and technical stand point. Doing this in Fedora makes the most sense; work there can flow in to EPEL[2], and sometimes then in to RHEL directly. This does not need to be an @redhat.com/@jboss.com person.
2. People to work the problem from various angles. There is going to be a bit of low-hanging fruit, some medium-hard, and an amount of very hard nuts to crack. Some of these people must be @redhat.com/@jboss.com, but maybe not as many as we think/fear.
What if … all of that? What next?
[1] http://fedoraproject.org/wiki/ISV_Special_Interest_Group
[2] http://fedoraproject.org/wiki/EPEL
Very good work. I’ve learned much more in one hour reading and installing Jboss this way than surfing hours on jboss wiki/forum.
Many Thanks, Craig !
Just finished deploying the enterprise version of the jboss portal (which contains the enterprise version of the jboss as server). This would be JBEPP on Fedora 8 on AWS, MySQL 5 DS.
JB AS running correctly is a grey zone. There are many components and cyclical inter-dependencies, it’s hard to know if they’re ever configured correctly without access to middleware developers. Basically, JB can break in 100^100 ways and still appear to work.
Packages would be better, but then my company wouldn’t be able to charge $$$ for installing jboss. 😉