aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giuseppe Gerla <>
Subject Re: Fwd: Re: Prototype for a new aries jpa impl
Date Fri, 10 Apr 2015 16:09:06 GMT
Hi Christian
I pushed on my fork 2 bundles to test jpa-experiments in an integrated
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

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...


2015-04-10 14:49 GMT+02:00 Giuseppe Gerla <>:

> 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 <>:
>> 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 <
>>> >:
>>>  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
>>>> Open Source Architect

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