6 Replies Latest reply on Dec 4, 2006 11:19 AM by Weston M. Price

    AOP/JCA

    Weston M. Price Master

      I have started replacing some of the more recongnizable areas of JCA with AOP most notablly Jms Tx Inflow as well as the JDBC support stuff (ExceptionSorter, ValidationConnectionChecker et).

      I am operating under the assumption that while we ultimately will move to a complete POJO/MC version, seperating these things now is a place to start.

        • 1. Re: AOP/JCA
          Weston M. Price Master

          Note, this would also be a good candidate for the XAResourceWrapper and Xid stuff we have to do to support WebSphereMQ and do a per CM pad option for the Xid.

          • 2. Re: AOP/JCA
            Juha Lindfors Master

            I'm looking at XAResourceWrapper right now as a build dependency for integrating JBoss Messaging and JBossTS to perform XA recovery when both services are deployed on AS.

            So if you manage to extract that out to a JAR smaller than the current jboss.jar, that would be great.

            • 3. Re: AOP/JCA
              Weston M. Price Master

              Excellent.

              The motivation for the JcaXAResourceWrapper is largely the same:

              1) Recovery made easier for JBossTS
              2) Overriding the isSameRM to fix 'broken' providers
              3) Jira task to move the Pad Xid stuff out of the XidFactory and have it be a configurable option per JCA deployment (ConnectionFactory or Endpoint (inflow)).

              Right now this is JCA specific but I don't see any reason why would couldn't do this as a general thing.

              • 4. Re: AOP/JCA
                Weston M. Price Master

                Next steps

                More design documents work
                Finish creating jca project structure (still need to resolve some Maven stuf)
                Check into SVN
                Start porting pieces of new JCA over to new project. This will be a combination (at least the spirit) of the JCA prototype in CVS as well as my current work.
                New links on the Wiki in the hopes of generating more contributor interest

                I haven't quite decided yet if the adapters should be a completely separate project, or should they be included as a sub-project of jca. Maven2 seems to support parent/child poms, so this should not be that big of a deal either way.

                Some tasks, programmtic deployment, RAR repository rely should be done against the new code base rather than having to shoehorn the existing JMX implementation to use this.





                • 5. Re: AOP/JCA
                  Adrian Brock Master

                   

                  "weston.price@jboss.com" wrote:

                  I haven't quite decided yet if the adapters should be a completely separate project, or should they be included as a sub-project of jca. Maven2 seems to support parent/child poms, so this should not be that big of a deal either way.


                  The idea of making the rars a seperate project was to stop people
                  introducing dependencies on the appserver, the connection manager
                  or anything else.

                  This was the reason why I even used a mock connection manager to test them.

                  • 6. Re: AOP/JCA
                    Weston M. Price Master

                    Umm...right. This is more of a build structure question versus *why* it was originally done that way. Just trying to get an idea of what people think.