Re: Fwd: Re: Prototype for a new aries jpa impl
First of all let me say that it's quite strange the behaviour that you described about tests. On my pc all tests run ok. I have only an excpetion during hibernate test due to class not found HibernateProxy (I think during class enhancement). So I think that we have to investigate better... but how? On my machine I have no error on testCache. About the transaction type, I first thinked to put it in the osgi service properties map, but there was some problems to retrieve it in the JpaInterceptor class. So finally I move it in the EMF map. However the JPA implementation ususally checks JPA standard property and then custom property. A not known property is not processed or generate only a warning. Finally, I think that we are well advanced, but I'm not sure that we are ready... I have some doubt on weaving functionality. However we can start to ask to the community and in parallel I can try to add some other tests. 2015-04-20 18:37 GMT+02:00 Christian Schneider ch...@die-schneider.net: Btw. No need for a pull request. I already merged your fork. What do you think about the current state of the code? I think we are ready to ask the aries community if this could be the base for the next major version. If we get green light I would propose to create a branch on aries for the current state of the jpa code which could then be used for maintenance. Our new code could then become the trunk and when we reach a good quality would be the aries jpa 2.0.0 version. WDYT? Christian On 19.04.2015 09:54, Giuseppe Gerla wrote: 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. -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Fwd: Re: Prototype for a new aries jpa impl
The tests work well with your complete sources. I observed that the hibernate test worked and the eclipselink test failed when I ran the tests against my original sources. I just wondered why the two persistence frameworks behaved differently. I like the way you solved the problem with the EntityManager properties. It allows the code to access the transaction type at any time while the service properties would have to be forwarded in a custom way. I know we are not yet feature complete. The reason why I think we should now ask about the future of aries jpa is that at apache the community should be involved from the start. So we should not wait till the code is completely polished. Of course we are already working in the open and everyone can engage but the code currently is on github which is not the common procedure at apache. If people are unsure we can also put our current code into a branch and do the switch on trunk at a later time. Christian On 20.04.2015 23:56, Giuseppe Gerla wrote: First of all let me say that it's quite strange the behaviour that you described about tests. On my pc all tests run ok. I have only an excpetion during hibernate test due to class not found HibernateProxy (I think during class enhancement). So I think that we have to investigate better... but how? On my machine I have no error on testCache. About the transaction type, I first thinked to put it in the osgi service properties map, but there was some problems to retrieve it in the JpaInterceptor class. So finally I move it in the EMF map. However the JPA implementation ususally checks JPA standard property and then custom property. A not known property is not processed or generate only a warning. Finally, I think that we are well advanced, but I'm not sure that we are ready... I have some doubt on weaving functionality. However we can start to ask to the community and in parallel I can try to add some other tests. 2015-04-20 18:37 GMT+02:00 Christian Schneider ch...@die-schneider.net: Btw. No need for a pull request. I already merged your fork. What do you think about the current state of the code? I think we are ready to ask the aries community if this could be the base for the next major version. If we get green light I would propose to create a branch on aries for the current state of the jpa code which could then be used for maintenance. Our new code could then become the trunk and when we reach a good quality would be the aries jpa 2.0.0 version. WDYT? Christian On 19.04.2015 09:54, Giuseppe Gerla wrote: 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. -- 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
Re: Fwd: Re: Prototype for a new aries jpa impl
OK Christian Ready to go... Il 21/apr/2015 06:57, Christian Schneider ch...@die-schneider.net ha scritto: The tests work well with your complete sources. I observed that the hibernate test worked and the eclipselink test failed when I ran the tests against my original sources. I just wondered why the two persistence frameworks behaved differently. I like the way you solved the problem with the EntityManager properties. It allows the code to access the transaction type at any time while the service properties would have to be forwarded in a custom way. I know we are not yet feature complete. The reason why I think we should now ask about the future of aries jpa is that at apache the community should be involved from the start. So we should not wait till the code is completely polished. Of course we are already working in the open and everyone can engage but the code currently is on github which is not the common procedure at apache. If people are unsure we can also put our current code into a branch and do the switch on trunk at a later time. Christian On 20.04.2015 23:56, Giuseppe Gerla wrote: First of all let me say that it's quite strange the behaviour that you described about tests. On my pc all tests run ok. I have only an excpetion during hibernate test due to class not found HibernateProxy (I think during class enhancement). So I think that we have to investigate better... but how? On my machine I have no error on testCache. About the transaction type, I first thinked to put it in the osgi service properties map, but there was some problems to retrieve it in the JpaInterceptor class. So finally I move it in the EMF map. However the JPA implementation ususally checks JPA standard property and then custom property. A not known property is not processed or generate only a warning. Finally, I think that we are well advanced, but I'm not sure that we are ready... I have some doubt on weaving functionality. However we can start to ask to the community and in parallel I can try to add some other tests. 2015-04-20 18:37 GMT+02:00 Christian Schneider ch...@die-schneider.net: Btw. No need for a pull request. I already merged your fork. What do you think about the current state of the code? I think we are ready to ask the aries community if this could be the base for the next major version. If we get green light I would propose to create a branch on aries for the current state of the jpa code which could then be used for maintenance. Our new code could then become the trunk and when we reach a good quality would be the aries jpa 2.0.0 version. WDYT? Christian On 19.04.2015 09:54, Giuseppe Gerla wrote: 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. -- 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
Re: Fwd: Re: Prototype for a new aries jpa impl
I also thought about putting the transaction type into the properties of the EMF service. This would avoid that we need to probe for the type. The problem is that this property is not specified by the jpa spec. So I was a bit hesitant to do so. It might be a good option to avoid the problem though. So I agree to do it this way. I just checked out your test bundle and itest. The hibernate variant seems to run fine. The eclipselink variant shows the exception with RollbackOnly in the testCache method. I wonder why they behavve differently. Christian On 19.04.2015 09:54, Giuseppe Gerla wrote: 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
Re: Fwd: Re: Prototype for a new aries jpa impl
Btw. No need for a pull request. I already merged your fork. What do you think about the current state of the code? I think we are ready to ask the aries community if this could be the base for the next major version. If we get green light I would propose to create a branch on aries for the current state of the jpa code which could then be used for maintenance. Our new code could then become the trunk and when we reach a good quality would be the aries jpa 2.0.0 version. WDYT? Christian On 19.04.2015 09:54, Giuseppe Gerla wrote: 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. -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Fwd: Re: Prototype for a new aries jpa impl
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
Re: Fwd: Re: Prototype for a new aries jpa impl
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
Re: Fwd: Re: Prototype for a new aries jpa impl
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
Re: Fwd: Re: Prototype for a new aries jpa impl
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
Re: Fwd: Re: Prototype for a new aries jpa impl
Hi Christian today I make some integration test in Karaf 2.4.1 using last version of jpa-experiments and my bundles. I found a problem about EmSupplierProxy. When the class TxBeanProcessor try to getTransactionType call preCall method of EmSupplierProxy that try to retrieve the osgi service instance of EmSupplier. The problem is that this service is registered after, so I have a NullPointerException (after wait 10 seconds). I try to increase the wait period to 100 seconds, but it seems that the registration of EmSupplier service is synchronous and postponed to the wait. I'm thinking that the problem is linked to my implementation of configuration management, because I move the registration of emf to the updated method. I will make a more detailed analysis tomorrow to find a solution. Regards Giuseppe 2015-04-07 22:04 GMT+02:00 Giuseppe Gerla giuseppe.ge...@gmail.com: Hi all I try to do some integration test deploying the new implementation with eclipselink and my test bundle. I make a change on the logic of PersistenceProvider service filter. To be abstract I don't want define the class of implementation in persistence.xml, so in this case I cannot filter using the class name. I found and fix also some minor issues. I open another pull request. However, I don't make several test (like transaction and so on), but from my point of the new implementation is more easy to manage of actual aries jpa. Regards Giuseppe 2015-04-07 11:54 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net: Hi guys, Giuseppe, I like your first implementation. I gonna take a deeper look this afternoon. Regards JB On 04/07/2015 10:23 AM, Giuseppe Gerla wrote: Hi Christian I open a pull request with the first implementation. I also add 2 unit test. It seems an easy implementation. Wdyt? 2015-04-07 10:21 GMT+02:00 Christian Schneider ch...@die-schneider.net : I am not yet sure how it would be implemented best. I guess you will have to experiment a bit. Why would ManagedEMF need to be a non static class? As far as I know non static classes are only possible as classes inside another class. Christian On 05.04.2015 11:44, Giuseppe Gerla wrote: Yes It could work... with ManagedService. But ManagedEMF should be changed in non static class and should implement ManagedService interface. Right? -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Fwd: Re: Prototype for a new aries jpa impl
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? 2015-04-08 22:00 GMT+02:00 Christian Schneider ch...@die-schneider.net: Thanks. Will also look into it. It could also be related to the check if the EnityManager is RESOURCE_LOCAL or JTA. Maybe we have to defer this check. In a new change I did not yet commit I removed most of the differentiation beetween JTA and RESOURCE_LOCAL in the jpa-blueprint module. After this change it might be easier to get it working. Christian On 08.04.2015 18:44, Giuseppe Gerla wrote: Hi Christian today I make some integration test in Karaf 2.4.1 using last version of jpa-experiments and my bundles. I found a problem about EmSupplierProxy. When the class TxBeanProcessor try to getTransactionType call preCall method of EmSupplierProxy that try to retrieve the osgi service instance of EmSupplier. The problem is that this service is registered after, so I have a NullPointerException (after wait 10 seconds). I try to increase the wait period to 100 seconds, but it seems that the registration of EmSupplier service is synchronous and postponed to the wait. I'm thinking that the problem is linked to my implementation of configuration management, because I move the registration of emf to the updated method. I will make a more detailed analysis tomorrow to find a solution. Regards Giuseppe 2015-04-07 22:04 GMT+02:00 Giuseppe Gerla giuseppe.ge...@gmail.com: Hi all I try to do some integration test deploying the new implementation with eclipselink and my test bundle. I make a change on the logic of PersistenceProvider service filter. To be abstract I don't want define the class of implementation in persistence.xml, so in this case I cannot filter using the class name. I found and fix also some minor issues. I open another pull request. However, I don't make several test (like transaction and so on), but from my point of the new implementation is more easy to manage of actual aries jpa. Regards Giuseppe 2015-04-07 11:54 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net: Hi guys, Giuseppe, I like your first implementation. I gonna take a deeper look this afternoon. Regards JB On 04/07/2015 10:23 AM, Giuseppe Gerla wrote: Hi Christian I open a pull request with the first implementation. I also add 2 unit test. It seems an easy implementation. Wdyt? -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Fwd: Re: Prototype for a new aries jpa impl
Hi Christian I open a pull request with the first implementation. I also add 2 unit test. It seems an easy implementation. Wdyt? 2015-04-07 10:21 GMT+02:00 Christian Schneider ch...@die-schneider.net: I am not yet sure how it would be implemented best. I guess you will have to experiment a bit. Why would ManagedEMF need to be a non static class? As far as I know non static classes are only possible as classes inside another class. Christian On 05.04.2015 11:44, Giuseppe Gerla wrote: Yes It could work... with ManagedService. But ManagedEMF should be changed in non static class and should implement ManagedService interface. Right? -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Fwd: Re: Prototype for a new aries jpa impl
I am not yet sure how it would be implemented best. I guess you will have to experiment a bit. Why would ManagedEMF need to be a non static class? As far as I know non static classes are only possible as classes inside another class. Christian On 05.04.2015 11:44, Giuseppe Gerla wrote: Yes It could work... with ManagedService. But ManagedEMF should be changed in non static class and should implement ManagedService interface. Right? -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Fwd: Re: Prototype for a new aries jpa impl
Hi guys, Giuseppe, I like your first implementation. I gonna take a deeper look this afternoon. Regards JB On 04/07/2015 10:23 AM, Giuseppe Gerla wrote: Hi Christian I open a pull request with the first implementation. I also add 2 unit test. It seems an easy implementation. Wdyt? 2015-04-07 10:21 GMT+02:00 Christian Schneider ch...@die-schneider.net: I am not yet sure how it would be implemented best. I guess you will have to experiment a bit. Why would ManagedEMF need to be a non static class? As far as I know non static classes are only possible as classes inside another class. Christian On 05.04.2015 11:44, Giuseppe Gerla wrote: Yes It could work... with ManagedService. But ManagedEMF should be changed in non static class and should implement ManagedService interface. Right? -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Fwd: Re: Prototype for a new aries jpa impl
Hi all I try to do some integration test deploying the new implementation with eclipselink and my test bundle. I make a change on the logic of PersistenceProvider service filter. To be abstract I don't want define the class of implementation in persistence.xml, so in this case I cannot filter using the class name. I found and fix also some minor issues. I open another pull request. However, I don't make several test (like transaction and so on), but from my point of the new implementation is more easy to manage of actual aries jpa. Regards Giuseppe 2015-04-07 11:54 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net: Hi guys, Giuseppe, I like your first implementation. I gonna take a deeper look this afternoon. Regards JB On 04/07/2015 10:23 AM, Giuseppe Gerla wrote: Hi Christian I open a pull request with the first implementation. I also add 2 unit test. It seems an easy implementation. Wdyt? 2015-04-07 10:21 GMT+02:00 Christian Schneider ch...@die-schneider.net: I am not yet sure how it would be implemented best. I guess you will have to experiment a bit. Why would ManagedEMF need to be a non static class? As far as I know non static classes are only possible as classes inside another class. Christian On 05.04.2015 11:44, Giuseppe Gerla wrote: Yes It could work... with ManagedService. But ManagedEMF should be changed in non static class and should implement ManagedService interface. Right? -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Fwd: Re: Prototype for a new aries jpa impl
forgot to send to list too Weitergeleitete Nachricht Betreff:Re: Prototype for a new aries jpa impl Datum: Sun, 05 Apr 2015 10:42:30 +0200 Von:Christian Schneider ch...@die-schneider.net Antwort an: ch...@die-schneider.net An: Giuseppe Gerla giuseppe.ge...@gmail.com I propose to use config admin with one config per punit instead of a plain file. The reason is that you probably will want to deploy the config together with your application. This would be a lot more difficult if there is one config for all persistence units and your deployment has to patch the config file. So I propose you use config admin with a ManagedService. The pid could look like a ManagedServiceFactory but probably it would be better to use a real MSF. So for each persistence unit you could publish a ManagedService with a pid of org.apache.aries.jpa.persistence-unit.cfg. The EMF creation would take place in the updated method of the ManagedService. When there is a null config it would take the default properties if a config is given it would take it. Would that work? Christian Am 05.04.2015 um 09:37 schrieb Giuseppe Gerla: Ok. I'm starting to implement using this scenario. Unit name is propertiesUnit. In the configuration file I search for: propertiesUnit.property-name = property-value So we will have one file for all persistence units. I want create e private method in the ManagedEMF class to retrieve all properties and use to create the EMF. Wdyt? Regards Giuseppe 2015-04-05 8:46 GMT+02:00 Christian Schneider ch...@die-schneider.net mailto:ch...@die-schneider.net: Hi Guiseppe, would be great if you can tackle that. Christian Am 04.04.2015 um 14:23 schrieb Giuseppe Gerla: Hi Christian Great idea. I understood the problem and yesterday I was thinking about a possible solution like yours. I'm thinking to use config admin in the parser of persistence.xml so to be able to use parameter value in the properties, but your solution seems more complete. If you want I can help you to develop this functionality. Thanks Regards Giuseppe 2015-04-04 10:24 GMT+02:00 Christian Schneider ch...@die-schneider.net mailto:ch...@die-schneider.net: Hi Guiseppe, I see your point. The problem though is that the EntityManagerFactory is created when the persistence.xml is read. At that point the EntityManagerFactory service is created. So the aries jpa xml or @PersistenceContext properties can only influence the creation of the EntityManager. So for you case this would not work. My proposal to use config admin would work though. Imagine we have a ManagedServiceFactory that reacts on configs like etc/org.apache.aries.jpa-*.cfg. In the config you set the persistence unit name and the properties you want to override. These properties would be read when creating the EntityManagerFactory. So this would allow you to even override the persistenceProvider. Christian Am 03.04.2015 um 09:44 schrieb Giuseppe Gerla: Hi Christian I understand your point of view, but I not agree. JPA define API, so it is an abstraction. My application MUST be independent from the implementation. Think about this. I have a software based on postgreSQL that use OpenJPA. For some reason a new customer buy my software with the constraint that it has to use MySQL. In this case, using your approach I have to use OpenJPA with MySQL, but this combination is not performing. From my experience, the best JPA implementation for mysql is Eclipselink. Using my approach I have the chance to deploy my software on mysql using eclipse without change the code!!! Not only. Using my approach, without change the code, I can do several test in the real environment to select the best combination between DBMS and JPA implementation from performance point of view. However, I have to say that write jpa query (using criteria builder) independent from the JPA implementation and from DBMS is a bit complex. I think that my use case is not so common, but I have this need and using Spring ORM can satisfy
