7 Replies Latest reply on Aug 30, 2006 3:19 PM by Ovidiu Feodorov

    Setting up JBoss Messaging integration tests

    Richard Achmatowicz Novice

      Dear Messaging

      I was asked by Ryan to incorporate targets into the JBAS testsuite for running Messaging against the existing JBossMQ integration tests. I'm running into some problems with this task, and need your advice.

      So far, I have added a target (not yet committed) to testsuite/build.xml to:
      (i) create a 'messaging' configuration
      (ii) start up JBAS with that configuration
      (iii) run the JBossMQ tests against JBAS
      (iv) shut down JBAS
      (v) delete the 'messaging' configuration

      Setting up the 'messaging' configuration was based largely on mimicking the target release-admin.xml in the Messaging1.0.1 distribution, as well as replacing jboss-remoting.jar, jboss-serialization.jar, jboss-aop.jar and jboss-aspect-library.jar with the modified versions in the deploy directory. Some of the JBossMQ tests are passing without change, so I suspect that the test case execution classpath and configuration I have set up are close to being what they should be.

      The problem i'm having is that a number of the JBossMQ test cases test implementation-dependent aspects of JBossMQ, which may or may not have a
      counterpart in Messaging. For example, the test case CleanTopicRemovalTestCase:
      - creates a topic
      - publishes a message to the topic
      - checks the state of the JBossMQ service MessageCache
      - deletes the topic
      - checks the state of the JBossMQ service MessageCache
      - the expected result is that message cache count (after) = message cache count(before) -1

      In order to produce a similar test case for Messaging, I would really need to know if a counterpart to MessageCache exists in Messaging, and whether that counterpart should exhibit the same behaviour. That question isn't easily answered, without looking in detail at the Messaging implementation and all the classes.

      So, i'm really uncertain as to what I should do here. A number of the JBossMQ test cases pass without change. Some fail for fairly simple reasons (e.g. user not defined), and these are easily fixed. Others fail because of implementation dependencies, as in the example I described, and are not so easily fixed.

      I'd like to ask your advice on this matter - for the short term goal of getting a subset of the integration tests up and running, what is the best approach to deciding which tests should be modified and retained and which discarded?

      On an unrelated point, the test cases will need to be modified (e.g. instances of object names changed from jboss.mq:service=DestinationManager to jboss.messaging:service=ServicePeer, for example). Should I create a new directory under testsuite/src/main/org/jboss/test, say messaging, to contain the new copies of the tests?

      Richard

        • 1. Re: Setting up JBoss Messaging integration tests
          Tim Fox Master

           

          "rachmatowicz@jboss.com" wrote:
          Dear Messaging

          I was asked by Ryan to incorporate targets into the JBAS testsuite for running Messaging against the existing JBossMQ integration tests. I'm running into some problems with this task, and need your advice.

          So far, I have added a target (not yet committed) to testsuite/build.xml to:
          (i) create a 'messaging' configuration
          (ii) start up JBAS with that configuration
          (iii) run the JBossMQ tests against JBAS
          (iv) shut down JBAS
          (v) delete the 'messaging' configuration

          Setting up the 'messaging' configuration was based largely on mimicking the target release-admin.xml in the Messaging1.0.1 distribution, as well as replacing jboss-remoting.jar, jboss-serialization.jar, jboss-aop.jar and jboss-aspect-library.jar with the modified versions in the deploy directory. Some of the JBossMQ tests are passing without change, so I suspect that the test case execution classpath and configuration I have set up are close to being what they should be.

          The problem i'm having is that a number of the JBossMQ test cases test implementation-dependent aspects of JBossMQ, which may or may not have a
          counterpart in Messaging. For example, the test case CleanTopicRemovalTestCase:
          - creates a topic
          - publishes a message to the topic
          - checks the state of the JBossMQ service MessageCache
          - deletes the topic
          - checks the state of the JBossMQ service MessageCache
          - the expected result is that message cache count (after) = message cache count(before) -1

          In order to produce a similar test case for Messaging, I would really need to know if a counterpart to MessageCache exists in Messaging, and whether that counterpart should exhibit the same behaviour. That question isn't easily answered, without looking in detail at the Messaging implementation and all the classes.


          Understood. Probably the best thing here is to ask is specific questions as to whether alternatives exist and we should be able to answer


          So, i'm really uncertain as to what I should do here. A number of the JBossMQ test cases pass without change. Some fail for fairly simple reasons (e.g. user not defined), and these are easily fixed. Others fail because of implementation dependencies, as in the example I described, and are not so easily fixed.

          I'd like to ask your advice on this matter - for the short term goal of getting a subset of the integration tests up and running, what is the best approach to deciding which tests should be modified and retained and which discarded?


          Best approach is probably to ask us and we should be able to answer :)



          On an unrelated point, the test cases will need to be modified (e.g. instances of object names changed from jboss.mq:service=DestinationManager to jboss.messaging:service=ServicePeer, for example). Should I create a new directory under testsuite/src/main/org/jboss/test, say messaging, to contain the new copies of the tests?

          Richard


          Sounds like a good idea. We don't want to touch the MQ tests in any way.

          • 2. Re: Setting up JBoss Messaging integration tests
            Ovidiu Feodorov Master

             


            Setting up the 'messaging' configuration was based largely on mimicking the target release-admin.xml in the Messaging1.0.1 distribution, as well as replacing jboss-remoting.jar, jboss-serialization.jar, jboss-aop.jar and jboss-aspect-library.jar with the modified versions in the deploy directory. Some of the JBossMQ tests are passing without change, so I suspect that the test case execution classpath and configuration I have set up are close to being what they should be.


            I would suggest using release-admin.xml directly That script is there to stay, as I don't see JBossMQ replaced by Messaging in the JBoss 4.0.x production releases in the near future. After clustering is done, yes, but not until the end of the year.

            release-admin.xml assumes a clean "default" 4.x distribution (JBossMQ included) and builds a "messaging" distribution based on it. It does everything that is necessary to create a consistent Messaging-enabled JBoss instance without any effort on your part. We test the installation procedure during our release sequence, so it's guaranteed to work. It would be much easier for you just to call it from your ant script.

            Also, keep in mind that we're working on separating the "jms" subtree from the 5.0 head so in the near future a messaging jar will be downloaded from the repository, along all other dependencies. However, this shouldn't affect you too much.


            The problem i'm having is that a number of the JBossMQ test cases test implementation-dependent aspects of JBossMQ, which may or may not have a counterpart in Messaging.


            Yes, we are aware of that.

            First of all, no JBossMQ-specific tests should be changed. JBossMQ should be tested as before, since we're supporting it in production. It is true that the place of those implementation-specific tests is not in the integration testsuite, but since JBossMQ is in the maintenance mode, the simplest solution is to not change anything and leave them as they are.

            In what Messaging is concerned, if a test is JBossMQ specific, ideally it should be duplicated and made JBossMQ-agnostic. I can help you with that on a case-by-case basis. Just send me the recipe to run the integration tests and a list of JBossMQ specific tests.

            In the end, the integration tests should test Messaging's JMS compliance and compatibility with other JEMS components, not Messaging internals. That's the job of the functional test suite.


            On an unrelated point, the test cases will need to be modified (e.g. instances of object names changed from jboss.mq:service=DestinationManager to jboss.messaging:service=ServicePeer, for example). Should I create a new directory under testsuite/src/main/org/jboss/test, say messaging, to contain the new copies of the tests?



            This point is very much related to the previous paragraphs. JBossMQ test must remain unchanged. For Messaging integration tests, there should be no "jboss.messaging:service=ServerPeer", but only JMS-specified interaction.

            • 3. Re: Setting up JBoss Messaging integration tests
              Richard Achmatowicz Novice

              Tim, Ovidiu

              Thank you for your very helpful comments and help in getting me started on this task!

              Some replies:
              1. Making use of release-admin.xml directly makes sense from the point of view of centralizing the code to create configurations. However, at present, we are pulling only pulling in jboss-messaging.jar into testsuite/thirdparty from repository.jboss.com, and don't have direct access to release-admin.xml. We are looking for a way to set up the configuration which makes life easy as well as being well-suited to the existing testsuite organization.

              2. The JBAS build and testsuite makes use of a number of names for directories relating to JMS and the existing JBossMQ implementation:
              trunk/messaging
              trunk/testsuite/src/main/jms
              trunk/testsuite/src/main/jmsra
              trunk/testsuite/src/main/jbossmq
              trunk/tetstsuite/src/resources/messaging
              trunk/testsuite/src/resources/jbossmq

              In incorporating these new Messaging tests, I tentatively chose the name messaging5 to be used as a basis for naming directories, files, and other related things.
              trunk/testsuite/src/main/messaging5
              trunk/testsuite/src/resources/messaging5
              ....
              This would allow me to keep all the new Messaging artifacts separate from the existing JBossMQ and JMS atrifacts, as you suggested.
              Is this name acceptable? Would another base name be preferable?

              Richard

              • 4. Re: Setting up JBoss Messaging integration tests
                Tim Fox Master

                I don't think messaging5 is a good name since it ties us to the 5.x release.

                Something like jbossmessaging sounds like a better choice to me.

                • 5. Re: Setting up JBoss Messaging integration tests
                  Ovidiu Feodorov Master

                   

                  rachmatowicz@jboss.com wrote:

                  1. Making use of release-admin.xml directly makes sense from the point of view of centralizing the code to create configurations. However, at present, we are pulling only pulling in jboss-messaging.jar into testsuite/thirdparty from repository.jboss.com, and don't have direct access to release-admin.xml. We are looking for a way to set up the configuration which makes life easy as well as being well-suited to the existing testsuite organization.


                  Ruel may have a say on this. The repository also provides a "resources" directory, that can be used for auxiliary scripts, I reckon. Quote from http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossBuild



                  Repository File Structure

                  ...
                  repository.jboss.com\component name\version\lib
                  repository.jboss.com\component name\version\resources
                  ...

                  resources - contains idl files, properties files, things of that nature

                  ...


                  rachmatowicz@jboss.com wrote:

                  2. The JBAS build and testsuite makes use of a number of names for directories relating to JMS and the existing JBossMQ implementation:
                  trunk/messaging
                  trunk/testsuite/src/main/jms
                  trunk/testsuite/src/main/jmsra
                  trunk/testsuite/src/main/jbossmq
                  trunk/tetstsuite/src/resources/messaging
                  trunk/testsuite/src/resources/jbossmq



                  "trunk/messaging" is a wrong name for JBossMQ related stuff to start with, I would change it to "jbossmq" everywhere it shows up in the source tree. Now with SVN is easy. This leaves messaging for us. As Tim said, messaging5 is bad.


                  • 6. Re: Setting up JBoss Messaging integration tests
                    Ruel Loehr Novice

                    The resource directory will indeed work for this.

                    • 7. Re: Setting up JBoss Messaging integration tests
                      Ovidiu Feodorov Master

                      SO there's our solution, Richard.