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 Thu, 09 Apr 2015 17:18:31 GMT
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
>
>

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