1 2 Previous Next 22 Replies Latest reply on Feb 22, 2010 6:08 PM by clebert.suconic



      Shouldn't undeployQueue on JMSServerManager also unregister the queue on management?



      It currently only unregisters JNDI.


      I understand undeploy shouldn't delete any data from the queue, but I guess any JMX Object associated with the queue should also be removed the JMX and Admin Console.



      I got a bunch of JMX Objects on my JMX console after I run the integration testsuite. All of the destinations are undeployed already.

        • 1. Re: JMSServerManager::undeployQueue

          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?

          • 2. Re: JMSServerManager::undeployQueue
            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.
            • 3. Re: JMSServerManager::undeployQueue

              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.

              • 4. Re: JMSServerManager::undeployQueue
                Can you clarify what do you mean by "clear the destination" ?
                • 5. Re: JMSServerManager::undeployQueue

                  destroy the destination... remove all the data content when a destination is undeployed.

                  • 6. Re: JMSServerManager::undeployQueue

                    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.

                    • 7. Re: JMSServerManager::undeployQueue

                      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.

                      • 8. Re: JMSServerManager::undeployQueue

                        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.

                        • 9. Re: JMSServerManager::undeployQueue

                          The issue is having to change a whole bunch of tests.


                          Remember.. this will have to me migrated into AS5 also.

                          • 10. Re: JMSServerManager::undeployQueue

                            Changing the semantics of undeploy to avoid having to change some tests is a hack.


                            Now, I assume you have abstracted out:


                            deploy destination

                            undeploy destination

                            create destination

                            delete destination


                            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...

                            • 11. Re: JMSServerManager::undeployQueue

                              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.

                              • 12. Re: JMSServerManager::undeployQueue

                                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.

                                • 13. Re: JMSServerManager::undeployQueue
                                  If all the tests are using a common infrastructure then it's just a call to deleteDestination in the tearDown(), or equivalent
                                  • 14. Re: JMSServerManager::undeployQueue

                                    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.

                                    1 2 Previous Next