aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Fwd: Re: Prototype for a new aries jpa impl
Date Thu, 09 Apr 2015 22:17:54 GMT
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.


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

View raw message