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