Hi Christian I checked code about exception raised during integration test in Karaf and I found an issue on transaction type retrieving method. Using magaed exception, eclipselink (but I think also hibernate) set transaction manager in rollback only state and this do fail the test. To avoid this behaviour I put the transaction type in the properties map of EntitiManagerFactory and then, when it is needed, I get it from the map.
I also change integration tests to manage the same service and same functionality with several implementation (eclipselink and hibernate). Now we have an example of my use case. Before I open a pull request, I'd like to know wdyt. 2015-04-15 14:43 GMT+02:00 Giuseppe Gerla <giuseppe.ge...@gmail.com>: > From my point of view, because we are working on a beta version of new > Aries JPA, the best way to proceed is to prepare a set of annotation > similar to JTA 1.2 and use it. > In this way we can complete our beta, test it and we are ready to delivery > the new Aries JPA when Karaf will be compliant with JTA 1.2. > If I can do something let me know. > > About your suggestion to use <tx:transaction method="*" value="Required" > /> in the bean definition, I try it but it didn't work. It seems that I > have to manually (by code) begin and commit the transaction. > Car test with eclipselink gives > javax.transaction.RollbackException: Transaction is marked for rollback > at > org.apache.geronimo.transaction.manager.TransactionImpl.registerSynchronization(TransactionImpl.java:147) > at > org.eclipse.persistence.transaction.JTATransactionController.registerSynchronization_impl(JTATransactionController.java:92) > at > org.eclipse.persistence.transaction.AbstractTransactionController.bindToCurrentTransaction(AbstractTransactionController.java:134) > at > org.eclipse.persistence.transaction.AbstractTransactionController.registerSynchronizationListener(AbstractTransactionController.java:431) > at > org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerWithTransactionIfRequired(UnitOfWorkImpl.java:4431) > at > org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper.registerIfRequired(JTATransactionWrapper.java:110) > at > org.eclipse.persistence.internal.jpa.EntityManagerImpl.getActivePersistenceContext(EntityManagerImpl.java:1957) > at > org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:863) > at > org.eclipse.persistence.internal.jpa.QueryImpl.performPreQueryFlush(QueryImpl.java:963) > at > org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:207) > at > org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:469) > at > net.lr.jpa.itest.service.impl.CarServiceWithSupplierImpl.getCars(CarServiceWithSupplierImpl.java:34) > Task test with hibernate gives > java.lang.NullPointerException > at > net.lr.txmanager.blueprint.JpaInterceptor.postCallWithException(JpaInterceptor.java:53) > at > org.apache.aries.blueprint.proxy.Collaborator.postInvokeExceptionalReturn(Collaborator.java:136) > at > org.apache.aries.blueprint.proxy.Collaborator.preInvoke(Collaborator.java:78) > at Proxya4faffee_6ed9_4df4_990d_596565ea8a97.addTask(Unknown > Source) > > > this evening I try to debug the application. Have you any suggestion? > > > > 2015-04-15 14:20 GMT+02:00 Christian Schneider <ch...@die-schneider.net>: > >> In the newest code I removed support for transactions and currently rely >> on aries transaction for that. >> If you use <tx:transaction method="*" value="Required" /> in your bean >> then it should work. >> The annotation based transactions that aries transaction also provide do >> not work for me. Unfortunately defined by aries transaction blueprint is >> also not very usable >> as you can not set it per class but only per method. >> >> I originally planned to work on aries transaction to better support >> annotation based transactions. Unfortuantely the code is quite tailored for >> xml described transactions. As the annotations are also not great I gave up >> on this for now. >> >> So I propose to write a new module that only covers annotation based >> transactions and also uses different annotations. Now the question is if we >> should define another set of annotations or just use the jta 1.2 >> annotations. These are nice but currently do not work in karaf. Upgrading >> to these is quite a lot of work. So I tend to wait with this part until >> karaf supports the jta 1.2 annotations. >> >> Another possibility would be to define our own set of annotations that >> are similar to jhe jta 1.2 ones and make sure the new transaction module is >> working with these but then wait for a release until jta 1.2 works in karaf >> and switch before the release. This way we would avoid another set of >> custom annotations and can still already test. >> >> WDYT? >> >> Christian >> >> >> On 15.04.2015 12:21, Giuseppe Gerla wrote: >> >>> Hi Christian >>> I'd like to know if you make some progress about jpa-experiments and >>> transaction. >>> >>> On my fork I create 2 bundles to make integration test and give you some >>> example of my use cases. >>> 1. jpa-container-testbundle is equivalent of yours jpa-blueprint-example, >>> but I add some code for caching. >>> 2. jpa-container-itest start karaf 2.4.1 environment and launch following >>> tests: >>> - TaskServiceImplTest.testPersistence is the same of yours but >>> without transaction management by code. This test fail because there is >>> no >>> transaction manager active >>> - CarServiceImplTest.testCache check that the service is able to >>> create a cache. This test pass. If you see the code the getColours method >>> use init method in "lazy fetch" mode. If you try to use init method by >>> blueprint file to initialize the bean you have an exception because the >>> EmSupplier is not ready. >>> - CarServiceImplTest.testDatabaseInitializationQuery check that >>> properties are passed to EMF correctly. This test pass. >>> - CarServiceImplTest.testAddQuery check that is possible to >>> insert >>> into db. This test fail because there is no transaction manager active >>> >>> >>> regards >>> Giuseppe >>> >>> >>> >>> >>> 2015-04-10 18:09 GMT+02:00 Giuseppe Gerla <giuseppe.ge...@gmail.com>: >>> >>> Hi Christian >>>> I pushed on my fork 2 bundles to test jpa-experiments in an integrated >>>> environment. >>>> I create to test classes. >>>> The first class is for non JTA (LOCL_RESOURCE) transaction that works >>>> using .begin(), .commit() by code. >>>> The second one is thinked to test JTA transaction. This test doesn't >>>> work >>>> because it is based on @Transaction annotation, but there is no >>>> transaction >>>> active. >>>> >>>> I have a question for you. Using Pax-exam and Junit to do the test, how >>>> can I enable the transaction support? I have no xml file... >>>> >>>> >>>> regards >>>> Giuseppe >>>> >>>> 2015-04-10 14:49 GMT+02:00 Giuseppe Gerla <giuseppe.ge...@gmail.com>: >>>> >>>> Sorry, for my misunderstanding. >>>>> Yesterday I saws rows in table but probably they were entered from the >>>>> first version of software that had transactions triggered by xml. >>>>> With annotation, it seems that insert work fine but there are no commit >>>>> on the database. So I have no new rows in table. >>>>> >>>>> I'd like to create (and I'm working on this topic) a bundle like >>>>> jpa-container-itest to do integration test of jpa-experiments. >>>>> I hope to commit a first draft of this bundle on my fork this evening. >>>>> >>>>> Regards >>>>> Giuseppe >>>>> >>>>> >>>>> 2015-04-10 0:17 GMT+02:00 Christian Schneider <ch...@die-schneider.net >>>>> >: >>>>> >>>>> Interesting. So you got the annotation based transactions working with >>>>>> aries transaction blueprint? >>>>>> Can you post your examples somewhere? >>>>>> >>>>>> I would also be interested in the necessary changes in your cache. >>>>>> Maybe >>>>>> we can also avoid that this is has to be done. >>>>>> >>>>>> Christian >>>>>> >>>>>> >>>>>> Am 09.04.2015 um 19:18 schrieb Giuseppe Gerla: >>>>>> >>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> http://www.talend.com >> >> >
