There are tests that need to validate the deployment of destinations through a XML. As we talked before that's a common use case within JBoss, hence they can't just call a method to create a destination and use tearDown.
The tests that are creating destinations programatically are fine.
So what you're saying, is you haven't actually abstracted out the AS test suite to work easily with any JMS provider?
If it has been abstracted out correctly, as discussed, then it should just be a matter of the JMS provider implementing an integration interface, and that's it. Is that not the case?
Tim wrote: "If it has been abstracted out correctly, as discussed, then it should just be a matter of the JMS provider implementing an integration interface, and that's it. Is that not the case?"
As I said, there are tests that are deploying JARs with XMLs on it.
on the MDB jar, you will have:
... . classes
On the MDB, there will be also a dependency on the deployer. The MDB can't be started before the destination was deployed. I have no control over when the deployer will kick in.. so I have to make sure the dependency injection from the micro-container would work properly here.
So, those tests are testing a different mechanism. They are testing deployers, dependency.. etc. I can't just remove the deployment xmls here and use a direct call on the setup. that would change the test and wouldn't replicate the expected use case.
Why can't you just make a call to deleteDestination once the test has completed? I don't get it
I can do that of course.
I would have to find what tests are deploying destinations through deployment descriptors and do it manually.
However I there are other tests outside of the AS6 testsuite that will need the same thing. It would be easier to change the behaviour during the testsuite only.
If the test is assuming that undeploy deletes a destination, then the test is invalid. It's as simple as that.
Undeploy does not delete a destination with HornetQ.
If someone writes an MDB to consume from a JMS queue, it's highly unlikely they would want this queue created and deleted every time the MDB was deployed/undeployed. That would make little business sense.
So I don't understand this use case and why you would expect undeploy to delete a queue. It makes no sense to me.
Undeploy != delete
I didn't want to change how this was working in production. I just wanted to have a hack for the testsuite only.
Anyway.. I will just change how the tests are deploying the destinations. Lets forget all this.