By unregister the queue on management I mean, remove all the JMX references and remove it from the registry.
Or this is what you guys expected?
Thats what i would expect, the same way deplyQueue will not throw an exception if the queue already exists it only adds it to jndi undeployqueue should only remove it from jndi.
Anyone see a problem if I make this configurable? a property on the hornetq configuration on how to undeploy destinations.
All the tests on the AS testsuite are expecting the undeploy to clear the destination. So, I would have some failures caused for stuff that is not cleared.
Of course I could change the tests to cleanup..
But changing the config would be so easier (even if we choose to keep it undocumented if we don't like users using it). I personally don't see a problem on letting the user choose anyway.
Can you clarify what do you mean by "clear the destination" ?
destroy the destination... remove all the data content when a destination is undeployed.
Undeploy does not mean destroying the destination - it just means removing it from JNDI.
If you want to destroy the destination, there are methods available to do this using the JMX, or management on the wire api.
I know that...
ON the deployers I wrote for the integration test, I'm doing the same behaviour.. i.e. undeploying from the JNDI only.
However, on the testsuite there are so many tests doing this kind of undeployment and they were expecting a destroy from the destination.
so, I want to have a property where I could decide if undeploy means destroy or just remove from the JNDI.
This propery could be just on the AS deployers if you like. It would be much easier than having to figure what tests are not clearing after their destinations.
I don't see the issue here.
If the tests needs the destination to be deleted on completion, then it can call the JMX method to delete the destination.
That's the correct way to do it in HornetQ.
The issue is having to change a whole bunch of tests.
Remember.. this will have to me migrated into AS5 also.
Changing the semantics of undeploy to avoid having to change some tests is a hack.
Now, I assume you have abstracted out:
via an interface which can be implemented by any particular messaging provider, thus allowing the JBoss AS test suite to be run against any JMS provider which implements that interface?
If that's the case, then all you need to do is implement the call to the JMX interface in the implementaion of the delete destination method.
Please don't tell you you've just hacked it to work like was done with the JBM integration...
yes, I have abstract that. I don't have a problem with those tests.
However there are a bunch of other tests spread through EJB3, MDBs, Servlets and JCA that are just deploying jars with hornetq-jms.xml on it. So, my methods are not being called.
I just want a hack for the testsuite. I don't want to change how the thing will work in production.
I can just add a property to the deployers itself without changing anything on the Hornetq's code for this.
If those other tests are assuming that undeploy also deletes a destination, then those tests need to be corrected.
Otherwise they won't work with other JMS providers either.
If all the tests are using a common infrastructure then it's just a call to deleteDestination in the tearDown(), or equivalent
I have written a new deployer for AS / HornetQ.
This mechanism will only work with hornetQ. Users won't use that with other providers.
I'm not abstracting the deployers.