Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Received-SPF: pass (athena.apache.org: domain of giuseppe.gerla@gmail.com
 designates 209.85.213.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5526FA92.7080008@die-schneider.net>
References: <5520F576.6080605@die-schneider.net>
	<5520F5A0.6060802@die-schneider.net>
	<CAMc5ysL2BfEvy_RabRm2NFfg6dPfw5Eaj25nJ9QoJN32kMHU2Q@mail.gmail.com>
	<552393A5.4020108@die-schneider.net>
	<CAMc5ysJOqYY=wbGzekCTkM0w-uTqvM6c5NVsHRZR-QWRus8_yA@mail.gmail.com>
	<5523A949.3060702@nanthrax.net>
	<CAMc5ysJTUkJBG-w22gnsZShaDmnii9DCUpHf2rR-hitePGNKhw@mail.gmail.com>
	<CAMc5ysJfhhbb=qZNDMXm302Mn6tkC8-gF0fLWtbKG9zU=pifUA@mail.gmail.com>
	<552588D9.5010701@die-schneider.net>
	<CAMc5ysKikBSJTHdBhgro1h_K_n6rm2zV0e3rmRaOZ2OtLt80Dw@mail.gmail.com>
	<552674AE.7070803@die-schneider.net>
	<CAMc5ysJiXbXzQD7mj5UW0zJ0Rq1GAQ7mEsBFGszQuCr9OiJC7Q@mail.gmail.com>
	<5526FA92.7080008@die-schneider.net>
Date: Fri, 10 Apr 2015 14:49:22 +0200
Message-ID: 
 <CAMc5ysKWWKJTfWEVdUHG6m_5Dhw00Rh_ftro4GwLwa74LvnECw@mail.gmail.com>
Subject: Re: Fwd: Re: Prototype for a new aries jpa impl
From: Giuseppe Gerla <giuseppe.gerla@gmail.com>
To: dev@aries.apache.org, Christian Schneider <chris@die-schneider.net>
Content-Type: multipart/alternative; boundary=089e0149c0a087f7cb05135e3159

--089e0149c0a087f7cb05135e3159
Content-Type: text/plain; charset=UTF-8

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

--089e0149c0a087f7cb05135e3159--