Seems like Spring requires the setup that is otherwise invalid:
serverPlatform.isJTAEnabled() == false; and
datasorceLogin.shouldUseExternalTrandsactionController() == true.
There is only one way to achieve that:
persistence unit must be configured to use JTA =>
datasorceLogin.shouldUseExternalTrandsactionController = true;
and
serverPlatform.isJTAEnabled() == false (currently by default only
for NoServerPlatform);
I understand that Spring calling em.getTransaction in JTA case is
against the spec., however the goal of Spring is to be transaction
mechanism agnostic (JTA vs no JTA use) so I don't see how else they
can do that.
If only we could somehow detect in predeploy that the persistence
unit is used with Spring then we could fix autodetection (if
Spring then NoServerPlatform or better serverPlatform.disableJTA()).
Otherwise alternatives are:
1. Remove server platform autodetection.
1.1 Pro: Spring users need no changes in their setup;
1.2 Con: Non Sprint users must specify server platform;
2. Keep server platform autodetection.
2.1 Con: Spring users must specify NoServerPlatform (or better a
newly defined SpringPlatform);
2.2 Pro: Non Sprint users need not specify server platform.
2.3 Pro: SpringPlatform would allow to use correct server platform
(wls, was) but with disabled jta, that would allow to perform
serverPlatform-specific actions correctly (like unwrapping data
source connection).
Thanks,
Andrei
On 2/6/2015 12:30 PM, Dmitry Kornilov
wrote:
> That
time I didn't dig deep enough. This case is complicated.
Can you
explain the scenario better so I can try to understand
what the problem is?
I have explained it more than once. Please scroll down the
history. It's there.
> Spring is widely
used. I don't know the exact statistic data but it could
be the most used case. I am still not sure that it's a
good idea to break it.
Sure, I get
that Spring is popular. Is this perhaps a bug in Spring's
usage of the EclipseLink / JPA APIs?
There is a bug? The defaults were used.
Rick, I don't think that we can convince each other. This
conversation gets useless and there is no point to continue it. I
would like to hear some fresh opinion from other committers.
Thanks,
Dmitry
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
|