aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giuseppe Gerla <giuseppe.ge...@gmail.com>
Subject Re: Fwd: Re: Prototype for a new aries jpa impl
Date Sun, 19 Apr 2015 07:54:45 GMT
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.gerla@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 <chris@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.gerla@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.gerla@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 <chris@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 <
>>>>>>> chris@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
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message