« Running Java: I | Main | Bruce Schneier: Automated Denial-of-Service Attack Using the U.S. Post Office »

Jboss: Making deployment less of a PITA

Anthony Eden: Deployment is a PITA

if you want to define a JMS queue you have to modify the file jbossmq-destinations-service.xml.

Instead of this, keep your own jms descriptor file in source control and deploy it onto JBoss along with the jar/ear. JBoss will pick up any file that ends in '-service.xml' in the default/deploy directory. Example:

<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id$ -->
<server>
<mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=iams.reachenvelope.in">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
<depends optional-attribute-name="SecurityManager">
jboss.mq:service=SecurityManager
</depends>
<attribute name="SecurityConf">
<security>
<role name="guest" read="true" write="true"/>
</security>
</attribute>
</mbean>
</server>

Granted this is not exactly well-documented (I took a good guess and it worked), but nothing in JBoss is.

Can we just expect JBoss to pick up our version of castor over the one that is in the lib directory? No. We must remove the one which is in the lib directory and copy our version into that directory.

There are two ways around this, both of which involve Ant. The first is to identify what jar you want gone and write some Ant to delete it as part of deployment. The second is better, but more work. Rewrite the the Jboss startup script in Ant. Yes, I've done this, yes, it works, and no I don't care about any possible weirdness in using Java to start Java. I did this to solve a nasty classpath problem. I extracted the classpth to a .properties file - much easier to work than a .bat file. After that I started up Tomcat with an Ant script, to see if it would work (yes) and just for fun, but now I think people should consider using Ant as the default mechanism for starting and stopping servers - and that means shipping JBoss et al with Ant files, not shell scripts.

It would be nice if there was some standard way of saying "execute this SQL code the first time this EAR is run".

Again Ant is our friend. Use a SQL task to run against the DB at deployment time. Although if JBoss used Ant, it could provide a system entity hook to do exactly what Anthony wants. It doesn't have to part of a J2EE deployment standard, just easy to do.

Later: from the comments, a good idea from Crowbar Tech:

...issuing arbitrary SQL when a bean is deployed. Simple create a trivial MBean that will execute any SQL passed via the configuring XML and include the according jboss-service.xml in the jar you deploy.


April 18, 2003 02:59 PM

Comments

Anthony Eden
(April 18, 2003 04:29 PM #)

Thanks for the tips Bill. The -service.xml is a good solution which I have heard about from someone else as well. Does file have to have the same name as the EAR file or can it have any name?

Bill de hra
(April 18, 2003 05:27 PM #)

Hi Anthony. The file can have any name, what matters to JBoss and your code are the queue names (which are shared across the descriptors and the service file).

The Crowbar In Chief
(April 18, 2003 09:29 PM #)

Bill;
Your first solution regarding the dynamic deployment of a new queue is also the key to the third issue, namely issuing arbitrary SQL when a bean is deployed. Simple create a trivial MBean that will execute any SQL passed via the configuring XML and include the according jboss-service.xml in the jar you deploy. We'll walk the walk and put together a proof of concept.
All in the pursuit of eliminating PITAs !
Cheers.

Martin Feeney
(April 28, 2003 03:45 PM #)

Hi,
Just wondering if u could help me i was wonder what would have to be included in the above xml service file to make a certain topic durable.

Tom Marrs
(October 21, 2003 11:45 PM #)

Bill,
Thanks for posting this - it was a HUGE help.
Another thing to consider is the order in which
JBoss instantiates things. We had to cut all files
from the default/deploy/jms directory and paste them into default/deploy so that JBoss would start the core JMS services before it deployed my JAR file.

I used your idea of a separate *-services.xml file
for declaring mbeans for my app's JMS destinations.

Anyway, that's how we were able to get things working and deploying smoothly without any exceptions and other JBoss whining.

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/987

Listed below are links to weblogs that reference Jboss: Making deployment less of a PITA:

» JBoss JMS from Mchel Foghl's Weblog
Spotted this useful tip on automating JBoss JMS queue setup: Jboss: Making deployment less of a PITA. [Read More]

Tracked on April 22, 2003 10:21 AM