Adding a JMS destination

You can add a JMS queue with the add-jms-queue command, which requires as mandatory parameter, just the name of the queue (–name parameter).

Here’s the synopsis of the command:

The only mandatory element is name, which specifies the queue name. The optional entries element includes a comma-separated list of JNDI names the queue should be bound under. If not present, the name will be used as the JNDI name. Next, the selector parameter can be added to specify a selector on the queue to filter messages. Then, the durable parameter specifies whether the queue should be durable or not (the default is true). Finally, notice the optional profile element, which can be used on domain configurations to specify the profile where the queue will be created.

The following command creates a new JMS queue named queue1 and bound under the JNDI queues/queue1 namespace:

We will not rehash the same description again for topics that are identical, except that has a smaller number of parameters; as a matter of fact the selector and durable parameters are not included here.

add-jms-topic –name=topic1 –entries=topics/topic1

Creating and modifying datasources

The CLI provides an useful data-source command to create a datasources. As the syntax of this command is a bit more wordy, you might find pretty useful to save it as a CLI script and adapt it to your needs.

Here’s the synopsis of the command:

Except for the profile_name, all the other parameters indicated are mandatory. That is, you need to specify if you want to add or remove a datasource. As far as it concerns parameters you need to state, at least, the JNDI name for the datasource (jndi-name) , the driver name (driver-name), the name of the connection pool (pool-name), and the connection URL (connection-url).

You can further customize the datasource, just as you would do in your standalone.xml file, by adding optional parameters; Let’s see a concrete example where we are creating a MySQL datasource.

The first thing we need is providing the JDBC-compliant driver, by deploying the JAR archive. Supposing you are using standalone mode, just copy the JDBC JAR file into the deployments folder:

Now, let’s verify that the driver has been correctly installed on the datasource subsystem. We can do this by means of the installed-drivers-list command on the datasources subsystem:

As you can see, there are two drivers installed: the default H2 driver and the MySQL driver that we have just installed.

Ok. Now we are ready to create a new datasource using the MySQL JDBC driver:

[standalone@localhost:9999 /] data-source add –jndi-name=java:/MySqlDS

–pool-name=MySQLPool –connection-url=jdbc:mysql://localhost:3306/MyDB

–driver-name=mysql-connector-java-5.1.16-bin.jar

–user-name=myuser

–password=password

–max-pool-size=30

If you are going to use an XA datasource class for your connections, then since the release 7.1.0 Beta, you need to operate on the resource path of the datasource.

Frequently asked Jboss Interview Questions

This requires at first creating the datasource with the minimal set of information:

/subsystem=datasources/xa-data-source=”MySqlDSXA”:add(jndi-name=”java:/MySqlDSXA”,

driver-name=”com.mysql”, pool-name=”mysqlPool”)

Then, you will add the datasource information as single properties:

/subsystem=datasources/xa-data-source=MySqlDSXA/xa-datasource properties=ServerName:add(value=localhost)

/subsystem=datasources/xa-data-source=MySqlDSXA/xa-datasource-properties=PortNumber:add(value=3306)

Now you can finally enable your datasource with:

/subsystem=datasources/xa-data-source=MySqlDSXA:enable

This was a bit more lenghty procedure however remember that you can use the key when you are creating the datasource to discover the initial properties and as well to add each single property.

Getting help from the CLI

If the syntax of CLI commands seem a bit overwhelming to you, don’t despair! Besides the tab completion functionality, the CLI has also got a man page for each command, just like the Unix shell.

If you issue a generic help command, the CLI will return a generic quick start guide to the interface. On the other hand, when passed as argument to a command, it provides an helpful description of the command synopsis and their arguments:

[standalone@localhost:9999 /] cd –help Synopsis:

cn [node_path]

cd [node_path] Description:

changes the current node path to the argument. Arguments:

node_path    – the new value for the current
node path following the format  [node-type [=node-name (,node-type[=node-name])*]].

The following navigation signs are supported in the node-path:     

– the root node (e.g. ‘cd /’ or ‘cd /some=thing’);           

– parent node (e.g. ‘cd ..’);     .type  

– node type of the current node (e.g. ‘cd .type’).

Executing CLI scripts in batch

The batch mode allows the execution of multiple CLI commands as an atomic unit. Just as an ordinary transaction, if any of the commands or operations fail, the changes are rolled back. On the other hand, if the execution ends without any error, changes are committed.

Not every command can be part of a batch. For example, navigation commands, such as cd, pwd, or help are excluded, because they do not reflect any change into the server configuration.

You can mark the beginning of a batch with the batch command. You will notice that you are in batch mode, because the prompt will now be marked by the sign #. In order to mark the end of the batch sequence, you have to use the run-batch command. Once completed, the executed batch will be discarded and CLI will exit batch mode. Here’s an example:

[standalone@localhost:9999 /] batch
[standalone@localhost:9999 /#] add-jms-queue –name=queue1 —
entries=queues/queue1
[standalone@localhost:9999 /#] deploy MDBApplication.jar
[standalone@localhost:9999 /#] run-batch
Before executing the batch, you can, at any time, get the list of batch commands, by
issuing the list-batch command:
[standalone@localhost:9999 /] list-batch
#1 add-jms-queue –name=queue1 –entries=queues/queue1
#2 deploy MDBApplication.jar

Advanced batch commands

Script batching can indeed be more complex than just starting and executing a list of commands. As a matter of fact, by pressing the Tab completion key when you are in batch mode, you should see several additional commands available. One of the most useful ones is the holdback-batch command, which can be used to temporarily pause
the batch of commands:
[standalone@localhost:9999 /# ] holdback-batch
In order to continue your batch of commands, just issue the batch command again:
[standalone@localhost:9999 /] batch
It’s even possible to save the batch by assigning an unique name, so that you can have multiple save points in your scripts:
[standalone@localhost:9999 /# ] holdback-batch step1
Later on, you can continue the execution, by specifying the holdback name:
[standalone@localhost:9999 /] batch step1
When executed with the –l parameter, the batch command provides the list of batch files that are held:
[standalone@localhost:9999 /] batch –l
step1
In the following table, we include the list of all available commands when you are running in batch mode: