Extracting the transactions from APE

[jmnarloch]

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.

[bmajsak]

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

[jmnarloch]

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.

[bmajsak]

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!

[jmnarloch]

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).

[jmnarloch]

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.

[bmajsak]

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!

[jmnarloch]

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)?

[jmnarloch]

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

[jmnarloch]

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