OK Christian
Ready to go...
Il 21/apr/2015 06:57, "Christian Schneider" ha
scritto:
> 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 pers
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 Ent
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?
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 cu
I also thought about putting the transaction type into the properties of
the EMF service.
This would avoid that we need to "probe" for the type. The problem is
that this property is not specified by the jpa spec.
So I was a bit hesitant to do so. It might be a good option to avoid the
problem th
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 be
>From my point of view, because we are working on a beta version of new
Aries JPA, the best way to proceed is to prepare a set of annotation
similar to JTA 1.2 and use it.
In this way we can complete our beta, test it and we are ready to delivery
the new Aries JPA when Karaf will be compliant with
In the newest code I removed support for transactions and currently rely
on aries transaction for that.
If you use in your bean
then it should work.
The annotation based transactions that aries transaction also provide do
not work for me. Unfortunately defined by aries transaction blueprint is
Hi Christian
I'd like to know if you make some progress about jpa-experiments and
transaction.
On my fork I create 2 bundles to make integration test and give you some
example of my use cases.
1. jpa-container-testbundle is equivalent of yours jpa-blueprint-example,
but I add some code for caching
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 du
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 thi
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
ResourceLocalTran
Thanks. Will also look into it.
It could also be related to the check if the EnityManager is
RESOURCE_LOCAL or JTA. Maybe we have to defer this check.
In a new change I did not yet commit I removed most of the
differentiation beetween JTA and RESOURCE_LOCAL in the jpa-blueprint module.
After t
Hi Christian
today I make some integration test in Karaf 2.4.1 using last version of
jpa-experiments and my bundles.
I found a problem about EmSupplierProxy. When the class TxBeanProcessor try
to getTransactionType call preCall method of EmSupplierProxy that try to
retrieve the osgi service instanc
Hi all
I try to do some integration test deploying the new implementation with
eclipselink and my test bundle.
I make a change on the logic of PersistenceProvider service filter. To be
abstract I don't want define the class of implementation in
persistence.xml, so in this case I cannot filter using
Hi guys,
Giuseppe, I like your first implementation. I gonna take a deeper look
this afternoon.
Regards
JB
On 04/07/2015 10:23 AM, Giuseppe Gerla wrote:
Hi Christian
I open a pull request with the first implementation. I also add 2 unit test.
It seems an easy implementation.
Wdyt?
2015-04
Hi Christian
I open a pull request with the first implementation. I also add 2 unit test.
It seems an easy implementation.
Wdyt?
2015-04-07 10:21 GMT+02:00 Christian Schneider :
> I am not yet sure how it would be implemented best. I guess you will have
> to experiment a bit.
>
> Why would Mana
I am not yet sure how it would be implemented best. I guess you will
have to experiment a bit.
Why would ManagedEMF need to be a non static class? As far as I know non
static classes are only possible as classes inside another class.
Christian
On 05.04.2015 11:44, Giuseppe Gerla wrote:
Yes
Yes
It could work... with ManagedService. But ManagedEMF should be changed in
non static class and should implement ManagedService interface.
Right?
Il 05/apr/2015 10:44, "Christian Schneider" ha
scritto:
> forgot to send to list too
>
>
> Weitergeleitete Nachricht
> Betreff:
forgot to send to list too
Weitergeleitete Nachricht
Betreff:Re: Prototype for a new aries jpa impl
Datum: Sun, 05 Apr 2015 10:42:30 +0200
Von:Christian Schneider
Antwort an: ch...@die-schneider.net
An: Giuseppe Gerla
I propose to use config admin with
20 matches
Mail list logo
