aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Fwd: Re: Prototype for a new aries jpa impl
Date Tue, 21 Apr 2015 04:57:11 GMT
The tests work well with your complete sources. I observed that the 
hibernate test worked and the eclipselink test failed when I ran the 
tests against
my original sources. I just wondered why the two persistence frameworks 
behaved differently.

I like the way you solved the problem with the EntityManager properties. 
It allows the code to access the transaction type at any time while the 
service properties would have to be forwarded in a custom way.

I know we are not yet feature complete. The reason why I think we should 
now ask about the future of aries jpa is that at apache the community 
should be involved from the start. So we should not wait till the code 
is completely polished. Of course we are already working in the open and 
everyone can engage but the code currently is on
github which is not the common procedure at apache.

If people are unsure we can also put our current code into a branch and 
do the switch on trunk at a later time.

Christian

On 20.04.2015 23:56, Giuseppe Gerla wrote:
> First of all let me say that it's quite strange the behaviour that you
> described about tests. On my pc all tests run ok. I have only an excpetion
> during hibernate test due to class not found HibernateProxy (I think during
> class enhancement). So I think that we have to investigate better... but
> how? On my machine I have no error on testCache.
>
> About the transaction type, I first thinked to put it in the osgi service
> properties map, but there was some problems to retrieve it in the
> JpaInterceptor class. So finally I move it in the EMF map. However the JPA
> implementation ususally checks JPA standard property and then custom
> property. A not known property is not processed or generate only a warning.
>
> Finally, I think that we are well advanced, but I'm not sure that we are
> ready... I have some doubt on weaving functionality.
> However we can start to ask to the community and in parallel I can try to
> add some other tests.
>
> 2015-04-20 18:37 GMT+02:00 Christian Schneider <chris@die-schneider.net>:
>
>> Btw. No need for a pull request. I already merged your fork.
>> What do you think about the current state of the code?
>> I think we are ready to ask the aries community if this could be the base
>> for the next
>> major version.
>>
>> If we get green light I would propose to create a branch on aries for the
>> current state of the jpa code which
>> could then be used for maintenance. Our new code could then become the
>> trunk and when we reach a good quality would
>> be the aries jpa 2.0.0 version.
>>
>> WDYT?
>>
>> Christian
>>
>> On 19.04.2015 09:54, Giuseppe Gerla wrote:
>>
>>> 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.
>>>
>>>
>>>
>>>
>> --
>> 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
View raw message