1 2 Previous Next 22 Replies Latest reply on Feb 22, 2010 6:08 PM by Clebert Suconic Go to original post
      • 15. Re: JMSServerManager::undeployQueue
        Clebert Suconic Master

        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.

        • 16. Re: JMSServerManager::undeployQueue
          Tim Fox Master

          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?

          • 17. Re: JMSServerManager::undeployQueue
            Clebert Suconic Master

            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:

             

            mdb.jar

            ... . classes

            hornetq-jms.xml

            ... meta-inf

                ejb-jar.xml

                jboss.xml

             

             

             

            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.

            • 18. Re: JMSServerManager::undeployQueue
              Tim Fox Master
              Why can't you just make a call to deleteDestination once the test has completed? I don't get it
              • 19. Re: JMSServerManager::undeployQueue
                Clebert Suconic Master

                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.

                • 20. Re: JMSServerManager::undeployQueue
                  Tim Fox Master

                  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.

                  • 21. Re: JMSServerManager::undeployQueue
                    Tim Fox Master

                    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

                    • 22. Re: JMSServerManager::undeployQueue
                      Clebert Suconic Master

                      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.

                      1 2 Previous Next