Creating destinations on the fly.....

[lolsson]

The JBOSS manual has the following to say about programmatic creation of destinations:

> Destinations may also be added on the fly, but the
> API has changed slightly. In 2.5.x destinations
> created this way will however only live as long as
> the server is up. When the JBoss server is rebooted,
> the dynamically created destinations will be gone.

I have written my owner deployer client application
that calls the JMSServer Mbean and the Deployer Mbean
to create destinations and deploy the application
using the destinations. The code that calls the
JMSServer mbean has logic like this:

 1) Parse ejb-jar.xml and extract info about destinations.
 2) For each destination found in ejb-jar.xml DO
 If destination can not be found in JNDI
 Call JMSServer mbean to create it

I want my destinations (queues) to be persistent,
but the comment in the manual seems to imply that
I cannot count on the queues being persisten across
server restarts in the future. Is that really the
case?

Will I have to modify my deployer to write into
the jboss.jcml file?

 1) Parse ejb-jar.xml and extract info about destinations.
 2) For each destination found in ejb-jar.xml DO
 If destination can not be found in JNDI
 Write dest entry to jboss.jcml :-(
 3) Make server re-read jboss.jcml?????

[pra]

The MDB already work this way, if destination does not exist, it is created (and removed when undeployed).

If nothing has changed recently, destination created through the MBean interface will be removed when server is restarted. Yes. Hiram, is this still correct?

In 3.0 you will however be able to deploy destinations through the new MLet *.sar deployment chema.

//Peter

[lolsson]

I understand that the MDB can be removed when it is not
consuming messages. That is OK. But I don't want the
queue itself to go away just because the server is
stopped and then restarted.

Assume for the sake of argument that the JBOSS server
is "empty" - there are no JMS destination in it and there
are no applications deployed into it.

If I then run my deployment client application, this
application will talk to the JMSServer mbean to create
queues and the Deployer MBean to deploy the actual
EJB application. Let's say that it consists of a
stateless session bean A and a message driven bean B
connected by a queue Q:

 A --> ----> B
 ! !
 ----> Q ---

Initially Q is empty.

Now a client calls a business method in A. In this
business method, which uses container managed
transaction support, a data item is written to the
queue Q. After the business method returns the
container will commit the operation so that the data
item really ends up in the persistent queue Q.
Then something bad happens (power failure) and the
JBOSS server is terminated.

When the JBOSS server is restarted it would be nice
if the data item was still in the queue so that B
can consume it. But if I understand the JBOSS docs
correctly, the queue Q will not even be around anymore
in Jboss 2.5.x because the queue was created
programatically.

Why will Jboss 2.5.x not keep programmatically
created queues across server restarts?

Lars

[hchirino]

The problem is that when when we had the jbossmq.xml file, we would update it to reflect addtions of queues and such. With us getting rid up the jbossmq.xml file and loading all the config info from jboss.jcml, we no longer update the config file to reflect the addition of the queue.

Long term, I think we will move to creating a *.sar style configuration for configuring queues/topics as that would allows us to add and remove queue configurations verry easily.

Regards,
Hiram

[lolsson]

Thanks for your reply.

So it seems my deployer app will have to try to update
the jboss.jcml file. While I am slightly disturbed by
this I suppose that this can be done. At least it
should be fairly easy to write code that adds entries
to jboss.jcml.

But is this safe? Does the JBOSS server survive
if this file is changed while the server is running?

Are there ways to tell a running JBOSS server that
it should re-read the file to pick up the most
recent changes? It would be a nuisance to have to
stop and restart the entire server just because
one queue / topic entry has been added to the file.

Lars