-
15. Re: Additions to the transaction SPI
marklittle Dec 4, 2013 11:04 AM (in response to mmusgrov)See other posting, but essentially I think "core" should be things that everyone needs and "extension" would be edge cases or specific groups that are either in development (may change between revs) or only needed by a few use cases that we know of today. Now maybe some things in "extension" eventually migrate to "core" based on feedback and growth of use.
-
16. Re: Additions to the transaction SPI
mmusgrov Dec 5, 2013 7:22 AM (in response to marklittle)So are you saying that I need to put the code in a separate repo (such as jbosstm/incubator · GitHub) and release it from there?
-
17. Re: Additions to the transaction SPI
marklittle Dec 6, 2013 6:35 AM (in response to mmusgrov)Didn't we resolve this yesterday? Nothing to do with the repo. More to do with how users gain access to the core and extension APIs, e.g., different JNDI bindings.
-
18. Re: Additions to the transaction SPI
mmusgrov Dec 6, 2013 6:51 AM (in response to marklittle)We did resolve it yesterday but my message pre-dated that discussion. Hope you don't mind me pasting that offline conversation (where it was resolved) here:
Mark Little wrote:
When I was doing the Web Services JSR years ago we ended up with a core SPI that was available via one JNDI name (say Foo) which contained all of the common operations across all of the various Web Services specifications and standards we wanted to support. Then there were extension SPIs which were available via different JNDI binding names (e.g., Bar, FooBar etc.)
The advantage was that we could isolate spec specific aspects to these extension SPIs so if they changed they'd only impact those users and not others.
-
19. Re: Additions to the transaction SPI
marklittle Dec 6, 2013 9:13 AM (in response to mmusgrov)A bit late if I did mind ;-)
-
20. Re: Additions to the transaction SPI
mmusgrov Dec 13, 2013 9:07 AM (in response to marklittle)I reworked the interface and it now contains a single class with a pair of methods to start and stop the transaction service. The start method checks to see if there is a JNDI provider present and, if so, makes sure that our standard interfaces are bound to that provider (UserTransaction, JTATransactionManager and TransactionSynchronizationRegistry). Also, behind the scenes, it registers TransactionDriver with java.sql.DriverManager and binds any required datasources into the JNDI tree.
So the ceylon.transaction implementation is simply: create a JNDI provider and then start the TM.
-
21. Re: Additions to the transaction SPI
marklittle Dec 13, 2013 9:22 AM (in response to mmusgrov)Looks good.
-
22. Re: Additions to the transaction SPI
tomjenkinson Dec 13, 2013 9:31 AM (in response to mmusgrov)Hi Mike,
Looks good to me.
Couple of observations:
Who calls these: narayana/ArjunaJTA/spi/src/main/java/io/narayana/spi/TransactionServiceFactory.java at JBTM-1699-spi · mmusgrov/narayana… and narayana/ArjunaJTA/spi/src/main/java/io/narayana/spi/TransactionServiceFactory.java at JBTM-1699-spi · mmusgrov/narayana…
Maybe should be private?: narayana/ArjunaJTA/spi/src/main/java/io/narayana/spi/TransactionServiceFactory.java at JBTM-1699-spi · mmusgrov/narayana…
How about some checks in start and stop to make sure that you don't register the driver twice etc?
Tom
-
23. Re: Additions to the transaction SPI
mmusgrov Dec 13, 2013 10:15 AM (in response to tomjenkinson)Who calls these: narayana/ArjunaJTA/spi/src/main/java/io/narayana/spi/TransactionServiceFactory.java at JBTM-1699-spi · mmusgrov/narayana… and narayana/ArjunaJTA/spi/src/main/java/io/narayana/spi/TransactionServiceFactory.java at JBTM-1699-spi · mmusgrov/narayana…
The intention was to report the JNDI names that the TM and UserTransaction are bound to. But I currently have that hard-coded on the ceylon end. Since the names are standard I think I will remove the methods. I agree with your other three comments.