Hi Christian good work! I make several test today and all works fine also with transaction. I use your example to inject EmSupplier in my service and use @Transaction annotation on methods that need it. I find only one restriction. In my previous service implementation I create an internal cache during the bean instantiation. This is a problem because the EmSupplier is created after during the configuration phase. So I changed my cache in a lazy cache and all works fine.
I hope during next days to go in detail of your examples. If you need more help to develop other feature let me know. N.B. I cannot test closure example because I don't use Java 8 Regards Giuseppe 2015-04-09 14:46 GMT+02:00 Christian Schneider <ch...@die-schneider.net>: > Sorry it took a little longer. I have now committed my changes. > In fact I removed the check in the BeanProcessor and do it now inside the > interceptor. > > Apart from that I worked on making the jpa code compatible to aries > transaction and making blueprint-jpa independent of jta. > The reason for this is that JTA can be used independently from jpa so it > makes sense to not mix both. For example we should be able to run JMS > and JPA in the same transaction. This would not work if we tie > transactions too much to jpa. > > While trying to integrate with aries transaction blueprint I found some > problems: > - annotation based transactions are implemented but do not work. I think > this is a bug in aries. The beanprocessor does not seem to be active. > - The aries @Transaction annotation is defined in a very unfortunate way. > It only applies to methods. In many cases you would simply want to annotate > a class with it. > Unfortunately I defined the copied transactions differently so they also > applied to classes. So there was a conflict between the two. I now > completely removed the transaction annotation from the jpa-experiments > code. If we want to use annotation based transactions we will have to use > different annotations anyway. I deferred this part for now. > > Apart from that the xml declared transactions from aries transaction > blueprint now work nicely together with the new blueprint-jpa module. The > example is defined this way now. > > For the closure based example I introduced a new TransactionType enum to > avoid using the aries one. > > So both examples should now work again. > > I also found that I forgot to implement the @PersistenceUnit support. This > is one possible next enhancement. > For transaction support I wonder if we can reuse aries transaction > blueprint. I am not sure to be honest. It is tailored a lot towards xml > based annotations with * based filters and such. I would be in favour of > dropping xml support completely for jpa and transactions and only have > annotations in the new code. Not sure if the community agrees though. > > Christian > > > > On 08.04.2015 22:24, Giuseppe Gerla wrote: > >> Yes, I verified that the problem is that the TxBeanProcessor check the >> transaction type in the following code >> >> Interceptor interceptor = (getTransactionType(supplierProxy) == >> PersistenceUnitTransactionType.JTA) ? >> new XaTxInterceptorImpl(tm, supplierProxy) : new >> ResourceLocalTransactionalInterceptor(supplierProxy); >> cdr.registerInterceptorWithComponent(beanData, interceptor); >> >> Did you remove this part? >> >> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
