9 Replies Latest reply on Aug 14, 2012 12:22 PM by Jakub Narloch

    Extracting the transactions from APE

    Jakub Narloch Novice

      Hi,

       

      I had made the first step towards moving the transaction support from Persistence Extension into to completly separate module: https://github.com/jmnarloch/arquillian-extension-transaction.

       

      As for my own requirements the current (draft) version already meets the expectations. I had implemented on top of that intial Spring Transaction support:

      https://github.com/jmnarloch/arquillian-extension-spring/tree/ARQ-958/arquillian-service-integration-spring-transaction

       

      I would like to discuss the shape of SPI, especially regarding the Arquillian Persistence Extension. Currently the transactions will be handled by concreate implementation of TransactionProvider:

       

      {code}

      public interface TransactionProvider {

       

          boolean supports(Class<?> testClass);

       

          void beginTransaction(Class<?> testClass);

       

          void commitTransaction(Class<?> testClass);

       

          void rollbackTransaction(Class<?> testClass);

      }

      {code}

       

      In my concept the supports() method will be used to determine if the provider can work with test class. In the spring module I had defined the @SpringTransactionConfiguration that will indicate that the transaction will be handled by SpringTransactionProvider. We could align the names so they would be identical with the APE.

        • 1. Re: Extracting the transactions from APE
          Bartosz Majsak Master

          Hi Jakub,

           

          better late the never, right?

           

          First of all kudos for all your great work you put to Arquillian ecosystem! It's invaluable contribution!

           

          I finally managed to spent some time on abstracted API / SPI and here are my findings.

           

          General feedback

          I think having transactional support as seperated extension with different adapters is a way to go! When I started with APE I followed pragmatic approach and simply implemented it as part of this extension itself. I totally agree that APE itself is not the place for this functionality and I've been always not so happy with it Since we finally have at least to real use cases for using transactions (APE using JTA and Spring extension relying on Spring goodies in this matter) it was just perfect timing from your side to came up with this proposal.

           

          My .2$

          1. Event precedence. We need to think how to address and handle precendence for transactional support to not overlap with other extensions [or simply
          2. Naming. Again for events. How about naming them as simple as BeforeTransactionStarted / AfterTransactionStarted and BeforeTransactionEnded / AfterTransactionEnded ? I think such consitent naming will be more natural.
          3. Transaction Context. What do you foresee for this specific context? In what kind of scenarios this might be handy?
          4. supports method. I'm not really convinced about this one. First of all we somehow assume that each test case will specifically define what kind of provider is used. This is a bit problematic in my eyes, because we clutter the code with more ceremony and also make it harder to adapt when we introduce change. I like the transparent way of containers support. What we might consider is either stick to the containers approach [one SPI implementation on the classpath] or do some lightweight configuration if we forsee a need to support more than one transaction manager for the tests. Anyway having support for multiple transaction manager on the test level is a bit too much of responsibility for the test itself. We should rather test the component which is accessing those and then container is taking care of transactions, right?

          Minor things

          1. Code formatting. I think we need to be consistent with how other modules are formatted currently. I know that JBoss changed formatting rules with AS7, but maybe it's better idea to do it for all ARQ code base in one go?
          2. Tests. Short topic - we need some tests for core module I will soon make some pull request to improve the situation there.

           

          Next Actions

           

          From my side I will abstract away JTA support from APE and make it SPI implementation of the transactional extension for the next release. There is one nitty gritty detail though which I believe we should address upfront. How should we manage these extensions?

          - as seperated implementations / github repos as you are already doing with spring-specific implementation?

          - all in one bag [multimodule mvn project sitting in one github repo]

          - github repo per specific implementation as it's done for containers?

           

          I hope Dan or Aslak could share some thoughts about this

           

          Last but not least, e should also consider concenrs and suggestions raised in this thread and maybe try to get some advices from Paul Robinson, as he is an expert in this field


          • 2. Re: Extracting the transactions from APE
            Jakub Narloch Novice

            Thanks Bartek

             

            I will try to address all the issues within next 2-3 days. I had already renamed the event names and removed the supports method. You don't need to worry about the javadocs and tests. I'm going to prepare them. Until now I delayed that a bit, so that we could dicuss the shape of the implementation in the general.

             

            As for the Transaction Context, I had been using the related @TransactionScope in Spring implementation. The TransactionStatus is stored within that scope. Overall I think of that as a nice addition.

             

            I will keep you posted with the progress.

            • 3. Re: Extracting the transactions from APE
              Bartosz Majsak Master

              Awesome. I saw usage of the TestContext after publishing the question. In fact it's handy and might be also used for internal implementation of the core - I will send small pull request today or tomorrow

               

              Cheers and keep up great work!

              • 4. Re: Extracting the transactions from APE
                Jakub Narloch Novice

                Hi again,

                 

                I've added javadocs to all of the classes and most of the unit tests. Hovewer the TransactionHandler still requires some extensive testing.

                 

                BTW. Aslak has already created for the extension seperate repository (https://github.com/arquillian/arquillian-extension-transaction).

                • 5. Re: Extracting the transactions from APE
                  Jakub Narloch Novice

                  Hi,

                   

                  I have finished the tests, so we could wrap up this phase a bit. If you have any other ideas that you would like to add, then be me guest

                   

                  In other to address some of the other issues:

                   

                  Event precedence. We need to think how to address and handle precendence for transactional support to not overlap with other extensions [or simply

                  In regards of Persistence Extension, the transactions are "triggered" with Before/After events so we only need to set the proper precedences. I don't not know whether we need to bother with other extensions at the moment.

                   

                  Code formatting. I think we need to be consistent with how other modules are formatted currently. I know that JBoss changed formatting rules with AS7, but maybe it's better idea to do it for all ARQ code base in one go?

                   

                  Hmm, I'm not using Eclipse, so got a bit problem with importing JBoss code formatter.

                  • 6. Re: Extracting the transactions from APE
                    Bartosz Majsak Master

                    Precedence is more like a general topic in my eyes, but yeah, wrt APE I just need to adjust it properly So now it's my turn to get it integrated.

                     

                    When it comes to code formatting - as I said it's minor thing, we shouldn't be that much concerned about at the moment.

                     

                    And by the way - congrats on passing mid term GSoC stuff!

                    • 7. Re: Extracting the transactions from APE
                      Jakub Narloch Novice

                       

                      And by the way - congrats on passing mid term GSoC stuff!

                      Thanks! Still lots of things to do and learn

                       

                      Should I open a pull request and move our little extension into the arquillian repository (https://github.com/arquillian/arquillian-extension-transaction)?

                      • 8. Re: Extracting the transactions from APE
                        Jakub Narloch Novice

                        There is a pending pull request, where you can comment the initial version: https://github.com/arquillian/arquillian-extension-transaction/pull/1

                        • 9. Re: Extracting the transactions from APE
                          Jakub Narloch Novice

                          We went live with the extension, by releasing the Alpha 1