8 Replies Latest reply on Apr 12, 2006 4:41 PM by Weston M. Price

    Long standing issues

    Adrian Brock Master

      Weston, I just assigned a couple of long standing issues
      to you. See the linked issues and discussion threads.

      The first isn't very important. It basically revolves around
      create a DataSource from a java(m)bean deployment
      or programmatically.
      The code that already exists is inside the rar.

      The second is the most important because it will greatly simplify
      the code we have to support for EJB2.1/3 and JBossMQ/JBoss Messsaging
      On the latter task, I'd prefer it if the jms inflow was based upon
      a generic framework for inbound messaging where "aspects" of
      the inflow could be plugged in. Leaving the user to just write
      some simple definition of what they want to use.

      But it is more important to get the jms inbound rar tested and
      production ready first.
      You can find some basic tests in "messagedriven" in the testsuite.
      Each test also has a counterpart test using the old JMSContainerInvoker.
      But this needs a lot more tests to cover all the functionality, including
      error checking and exceptionlistener handling.

        • 1. Re: Long standing issues
          Adrian Brock Master

          Weston, you know those JIRA comments go in the release notes.

          JIRA should just be a record of what needs doing,
          how it was fixed and whether there are any workarounds.

          If you need to make a comment do it here in the forums.

          • 2. Re: Long standing issues
            Adrian Brock Master

            Another long standing issue is this:
            http://jira.jboss.com/jira/browse/JBREM-236 + linked.
            Which Tom still has at low priority.

            This has been broken since the 4.0.0 release and Tom wrote the original
            but hasn't been supporting it, despite me prodding him to get the
            issues fixed.

            I've got to the point where I tell people this feature doesn't exist.
            It is just their imagination. It is fundamentally broken. ;-)

            • 3. Re: Long standing issues
              Weston M. Price Master

              Quick question. I am assuming that we are targeting most of this work, save maybe the aspectized inflow stuff for the 4.x generation. Is this correct? It would seem that we can do most of this stuff in current time frame rather than targeting the 5.0 stuff.

              Let me know if I am being stupid.

              • 4. Re: Long standing issues
                Adrian Brock Master

                Everything on this thread should be done in the 4.0.x branch.

                • 5. Re: Long standing issues
                  Weston M. Price Master

                  As far as the programatic *-ds.xml deployment stuff, I thought following the basic design of the RARDeployer would be a good fit. Basically use JBossXB in conjunction with a new DSDeployer to accomplish what we do for *.rar files now. This new deployer would of course allow for programmatic deployment as well.

                  New package structure would look something like


                  etc, etc.

                  • 7. Re: Long standing issues
                    Weston M. Price Master

                    As far as the inflow stuff goes, I thought as a 'pseudo' test, and one that can enhance and complete the documentation on the Wiki would be to fully integrate WebSphereMQ with JBoss, filling in the last piece of having an MDB listen to a WebSphereMQ instance. I have the software at my disposal. While this wouldn't go into the testsuite proper, I think it would be a viable solution for 'kicking the tires' of the inflow stuff. Maybe some other issues will shake out.

                    This would more like as not be down with WebSphereMQ 6.0, seing as this actual supports the latest JMS stuff.

                    I have seen quite a few people asking for examples of this type of configuration...while I have the patient open, might be worth the day or so to set this up.

                    • 8. Re: Long standing issues
                      Weston M. Price Master

                      Looking into the JBossXB stuff to handle the *-ds.xml deployment. The working model I am using right now, and coding to is the idea of an AbstractConnectionFactoryMetatData which can either represent a ConnectionFactoryMetaData or a DataSourceMetaData. While I am working on this I am operating under the assumption that pooling specifics, transaction specifics etc, etc, can also be expressed generically with the appropriate subtypes

                      Further, 'aspects' of the pool (criteria), or the connection itself (transaction support) are also generic.

                      Ideally, it would be interesting to factor out pooling information that has primarily to do with LifeCycle management (size, blocking-timeout, etc, etc) and subtype specific values such as the valid-connection-checker, sql etc, etc.