10 Replies Latest reply on Aug 23, 2005 2:13 PM by ovidiu.feodorov

    jms tools, abstraction and not invented here

      What are these tools?

      One of the reasons for writing the new JMS was to avoid the
      "not invented here" syndrome of JBossMQ.

      Which basically means that any improvements to JBoss in general are not
      reflected in JBossMQ, and it also complicates integration, e.g.
      http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQDB

      If you cannot find what you need in the rest of JBoss, then please
      raise a feature request asking for what you need.

      This project is responsible for messaging, period. That is your concern.

      The JMS project is NOT the place to decide integration issues.
      You need an interface and an implementation that does what you need.
      Both provided by the project that is responsible for that concern.
      http://jira.jboss.com/jira/browse/JBAS-1796

      If these are just mocks for testing purposes, then these classes belong in
      the "test" framework project where other projects can use them, or the
      mock should be provided by the project that defines the service.
      e.g.
      NoopInvoker belongs in the server module.
      InVM naming context belongs in the naming module (although jnp can already
      be configured to do this).
      etc.

        • 1. Re: jms tools, abstraction and not invented here

          You should at least have a separate src/tests (or you called it tests/src)
          so we can properly differentiate the real implementation from your test code.

          • 2. Re: jms tools, abstraction and not invented here

            And having your own private version hsqldb makes no sense,
            especially when there is no documentated FIXME to explain it:
            http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&pid=12310061&statusIds=1

            • 3. Re: jms tools, abstraction and not invented here
              ovidiu.feodorov

               

              What are these tools?

              One of the reasons for writing the new JMS was to avoid the "not invented here" syndrome of JBossMQ.


              "tools" is essentially a collection of JMX wrappers that allows me to register JBoss services with a MBeanServer and test JMS code against real JBoss code that belongs to other projects. This allows me to start a extremely small version of the microkernel in memory for testing purposes. So everything you see there is a facade for things "invented somewhere else". Which basically means that any improvements to JBoss are immediately reflected in JBoss Messaging even from the test unit phase.

              This project is responsible for messaging, period. That is your concern.


              Messaging cannot be achieved without transactions, persistence and security. I need these services for my tests.


              If these are just mocks for testing purposes, then these classes belong in the "test" framework project where other projects can use them, or the mock should be provided by the project that defines the service. e.g. NoopInvoker belongs in the server module. InVM naming context belongs in the naming module (although jnp can already be configured to do this). etc.


              This is an interesting and certainly a very good idea, but it is new to me. Let me tell you what I did so I came up with this set-up:

              * I realized that I need (for example) a managed connection for testing. I had a choice to write my own or use something that's already out there.
              * I decided that I don't want to write a ManagedConnection and a ManagedConnectionFactory, so I turned to what already exists in JBoss.
              * I had to use it somehow, so I needed some sort of testing strategy.
              * I searched jboss.org for "testing", "testing strategy", "integration", "test mock". I didn't find any document that would help me.
              * I looked into wiki. There is no upper level link that would help me to find the answer to my question.
              * I looked into JBoss Development Process Guide http://jira.jboss.com/jira/browse/JBLAB-7. The document doesn't address this issue.
              * Finally I decided for a solution that will have the minimal impact on other projects, while allowing me to use as much existing code as possible.

              There are thousands of JIRA issues and forum posts. If you think that a crosscutting concern is identified and it is worth extracting and shared with others, why don't you write a wiki page that will serve as aggregation point for that idea, and very important, it is under your control so it won't be polluted with noise. It is very difficult to track a thirty or more message thread, especially when new ideas are being exchanged and half of them are dropped by the end of the thread.

              For this specific case, why don't you start a top level wiki page called DevelopmentProcess? Under that, you should have a link named TestingStrategy or similar, and everybody will know where to look.

              You should at least have a separate src/tests (or you called it tests/src)


              Excerpt from "JBoss Development Process Guide" http://jira.jboss.com/jira/browse/JBLAB-7

              "Functional tests need to be located in the module which they test. The testsuite needs to be able to include these in the "tests" target.
              To contribute functional tests to the testsuite, each module should contain a tests directory with with a build.xml. [...] The testsuite/build.xml will include a functional-tests target which uses the task to call the funtional-tests target on each module's tests/build.xml."

              So I called the directory the way JBoss Development Process Guide tells me to.

              And having your own private version hsqldb makes no sense


              This is the sense:

              I needed the source code for debugging. JBoss is currently using hsqldb 1.8.0RC3 but I was only able to find source code for 1.8.0.1 or 1.7.3 or lower, unless I went through complicated CVS maneuvers, which I was not willing to. So I used 1.8.0.1. More than that, the default HSQLDB build is compiled with debug off, and I had to recompile it with debug on, to be able to run a debugger on it.

              This is an idea: for each jar, the thirdparty directory shoul also keep its associated src.jar, so it would save time for those who want to debug the thirdparty module.




              • 4. Re: jms tools, abstraction and not invented here

                The "test" framework is (not :-) being done under this task:
                http://jira.jboss.com/jira/browse/JBAS-1768

                • 5. Re: jms tools, abstraction and not invented here

                  This all sounds reasonable, but what it shows is a lack of communication.

                  A few posts in the dev forums or the dev list will get you some feedback
                  and no response is just "silence means approval" (or people don't care :-).

                  That way, everybody knows what is happening, or can look back through their
                  mail archive to see why something was done.

                  • 6. Re: jms tools, abstraction and not invented here
                    ovidiu.feodorov

                    You're asking too much from me if you want me to keep track of every JIRA task that is, man. I still think that Wiki documents, as aggregation points, are a good idea.

                    However, speaking of abstraction, if you need my experience in using interfaces and implementations, I am up for it. Our micro-micro-kernel, as Tim and I use to call it, works beautifully for testing.

                    I agree that "tools" shouldn't live under the main source tree, but under tests. I will change that.

                    • 7. Re: jms tools, abstraction and not invented here

                      On the "not disrupting other projects".

                      We need to know about problems/issues earlier rather than later.

                      Besides, I don't know about you, but when I leave things lying around for later,
                      I forget about them.
                      So I raise JIRA tasks or add @TODO/FIXME in the source code to remind me.

                      I don't see why hsqldb wasn't compiled with debug anyway?
                      The benefits of being able actually debug problems far outweighs any micro-efficiencies
                      that the compiler does (assuming the JIT cannot reproduce them at runtime anyway ;-)

                      • 8. Re: jms tools, abstraction and not invented here

                         

                        "ovidiu.feodorov@jboss.com" wrote:
                        You're asking too much from me if you want me to keep track of every JIRA task that is, man. I still think that Wiki documents, as aggregation points, are a good idea.


                        This is from the list of changes for 4.0.3
                        Don't you read the roadmap? :-)

                        • 9. Re: jms tools, abstraction and not invented here

                           

                          "ovidiu.feodorov@jboss.com" wrote:

                          However, speaking of abstraction, if you need my experience in using interfaces and implementations, I am up for it. Our micro-micro-kernel, as Tim and I use to call it, works beautifully for testing.


                          And here's a better one. JBossAS inside a unit test:
                          http://www.jboss.org/index.html?module=bb&op=viewtopic&t=63480

                          Bill's done a lot of work on this for EJB3 standalone, since that prototype.

                          • 10. Re: jms tools, abstraction and not invented here
                            ovidiu.feodorov

                            This JIRA issue pretty much summarizes the entire discussion: http://jira.jboss.org/jira/browse/JBMESSAGING-123