1 2 3 Previous Next 37 Replies Latest reply on Jun 23, 2006 5:08 AM by adrian.brock Go to original post
      • 30. Re: EJB3 JCA/JMS Integration

        That integration was just the JMX version of the ResourceAdapter api.

        Even if it wasn't JMX it would NOT require "connector" implementation
        details.

        All you need is a MessageEndpointFactory and an ActivationSpec
        then invoke on the ResourceAdapter.

        None of this requires org.jboss.resource in EJB3 classes.

        What it does require is some wiring. Wiring is an issue for the
        Micro[container|kernel] not connector or EJB3.

        If it can't be made to work, then say so, we can fix it.
        Don't mung it by creating tight coupling and
        unmaintainable/unsupportable code.

        • 31. Re: EJB3 JCA/JMS Integration

           

          "bill.burke@jboss.com" wrote:

          I don't want Bill held up until some "brainiac" discovers his holy grail SPI interface. Iterate. I'm sick of everything having to be perfect for you guys before we can do anything.


          And I'm sick that you are still "iterating" crap 6 months after I raised the
          issue. In fact it is longer than that, but I didn't raise earlier because
          I was told you were "iterating".

          You'll notice I haven't done any work on EJB3.
          I'm too scared to look at the code... :-)

          And there's nothing "holy grail" about defining a bloody interface
          instead of poking around inside the guts of somebody else's
          unstable implementation where you are not wanted.

          If you do the latter, don't be surprised when it breaks.
          And don't go raising bug reports when there are no tests
          to prove the thing was intended to be used that way.

          • 32. Re: EJB3 JCA/JMS Integration
            bill.burke

             

            "adrian@jboss.org" wrote:
            "bill.burke@jboss.com" wrote:

            I don't want Bill held up until some "brainiac" discovers his holy grail SPI interface. Iterate. I'm sick of everything having to be perfect for you guys before we can do anything.


            And I'm sick that you are still "iterating" crap 6 months after I raised the
            issue. In fact it is longer than that, but I didn't raise earlier because
            I was told you were "iterating".

            You'll notice I haven't done any work on EJB3.
            I'm too scared to look at the code... :-)

            And there's nothing "holy grail" about defining a bloody interface
            instead of poking around inside the guts of somebody else's
            unstable implementation where you are not wanted.

            If you do the latter, don't be surprised when it breaks.
            And don't go raising bug reports when there are no tests
            to prove the thing was intended to be used that way.


            The point is, you're being an condescending asshole when Bill D is trying to do the right thing, which is: make MDB3's purely RAR based. This task is a *SCHEDULED* JIRA task for next EJB3 release.

            His bug is probably a bug in the JMS RAR as the new MDB3 implementation Bill is working on is based on pure Message Inflow only.

            It is not BIll's job to

            a) define an SPI
            b) test an SPI

            nor is it the job of the EJB3 team. As you said.

            That being said, Bill and the EJB3 team should not be blocked because some brainiac like you or Weston are busy doing something else.

            All BIll needs is an SPI for:

            1) ActivationSpec creation (no spec API for this?)
            2) finding the RA (so that endpointActivation/deactivation can be invoked properly)

            In the meantime, there's absolutely no reason he can't write his own abstraction to do #1 and #2 (which he is doing). In fact, he has to write his own abstraction anyways so that it works on JBoss4.x, E-EJB3, JBoss5.

            • 33. Re: EJB3 JCA/JMS Integration
              bdecoste

               


              None of this requires org.jboss.resource in EJB3 classes.


              The only place that the EJB3 code references the org.jboss.resource package is in some of my recent work for E-EJB3 and I am currently working to remove this dependency and was removing it long before this thread was started. It's there only as a starting point for me. There are no references to org.jboss.resource in the ejb3 mdb or inflow code



              • 34. Re: EJB3 JCA/JMS Integration
                starksm64

                There is little coming out of the ejb3 development in terms of contract proposals on which other teams can do any reasonable iteration. Get this started and everyone will quit bitching about your island development model.

                • 35. Re: EJB3 JCA/JMS Integration
                  bill.burke

                   

                  "scott.stark@jboss.org" wrote:
                  There is little coming out of the ejb3 development in terms of contract proposals on which other teams can do any reasonable iteration. Get this started and everyone will quit bitching about your island development model.


                  I give up. You win. Sacha and Carlo (the actual implementer) agree with you so poopoo on me. Carlo will finish what he has so that we have something usable in E-EJB3 until JCA Timer is completed.

                  BTW, Screw your "island development" comment. Message Inflow and MDB is being cleaned up right now (was started a few weeks ago), JEE5 injection for tomcat was discussed a few weeks ago and work has already been done at least to share XML parsing metamodels. I'm starting work on the rest of that now. There is already an ad-hoc abstraction between JB4 and MC in ejb3 codebase that could be abstracted out. Don't get pissy with me because I disagree with you on one thing.



                  • 36. Re: EJB3 JCA/JMS Integration

                     

                    "bill.burke@jboss.com" wrote:

                    The point is, you're being an condescending asshole


                    Agreed. :-)


                    This task is a *SCHEDULED* JIRA task for next EJB3 release.


                    A "quick and dirty".


                    His bug is probably a bug in the JMS RAR as the new MDB3 implementation


                    Agreed, but since there already is a JIRA issue linked to this thread
                    saying the JMS RAR is untested (doesn't work) it is unsurprising.
                    It is top of Weston's priorities.
                    Raising duplicate bug reports is pointless.


                    It is not BIll's job to

                    a) define an SPI
                    b) test an SPI

                    nor is it the job of the EJB3 team. As you said.


                    It is if he doesn't want to discuss it first and just ploughs
                    through somebody else's project.


                    All BIll needs is an SPI for:

                    1) ActivationSpec creation (no spec API for this?)
                    2) finding the RA (so that endpointActivation/deactivation can be invoked properly)

                    In the meantime, there's absolutely no reason he can't write his own abstraction to do #1 and #2 (which he is doing). In fact, he has to write his own abstraction anyways so that it works on JBoss4.x, E-EJB3, JBoss5.


                    That is all I am asking for. Once you have your interface
                    you can do whatever "quick and dirty" you like to implement it
                    IN THE JCA PROJECT where we know it exists and have tests
                    to show how you expect it to work.

                    Spreading ad hoc integaration code around the code base
                    doesn't scale and is doomed to failure.

                    Consider when "Joe JCA programmer" in 6 months time
                    refactors the code. He has no idea how you use it in the EJB3 project.
                    More importantly, nor should he care if there isn't a test to catch
                    his regressions. Lack of a test for how you use it, is your fault.

                    • 37. Re: EJB3 JCA/JMS Integration

                      Let me make a more constructive comment
                      (but equally condenscending :-)

                      Procedure: Integration 101

                      1) Define an integration point (e.g. ResourceAdapterFactory)
                      2) Implement the integration point in the providing project (JCA)
                      3) Unit test the integration point in the providing project (currently testsuite)
                      4) Consume the integration point in the consuming project (EJB3)
                      5) Test the integration (EJB3)

                      1 2 3 Previous Next