|Re: [eclipselink-dev] Fix for 455683. Add support to automatically detect the target server.|
I would like to reopen a discussion about server platform auto detection. We continue to receive complains from our customers about breaking the backwards compatibility.
I briefly repeat what the problem is for people included in CC. After adding server platform auto detection in early Jan 2015 the default behavior of EclipseLink is changed. If in persistence.xml a target platform and transaction type are not defined in some cases "Cannot use an EntityTransaction while using JTA" exception is thrown. It happens because WLS platform gets auto detected and transaction type is switched to JTA. Which is not the desired behaviour in some cases. See the table below:
Previous Version New Version
Server Platform: NoServerPlatform Weblogic_XX_Platform
Transaction type: ResourceLocal JTA
It often happens when Spring is used. Spring manages transactions itself and requires "local resource" transaction mode.
As Rick mentioned, the spec says that if the transaction-type isn't specified in an EE container it defaults to JTA. It also mentions that if a persistence unit is using RESOURCE_LOCAL that a non-jta-datasource will be provided. This is correct, but the spec doesn't say that server platform has to be detected automatically. It just says that if a JEE platform is set in persistence.xml then use JTA transaction type by default.
There are some workarounds:
1. Specify NoServerPlatform in persistence.xml: <property name="eclipselink.target-server" value="None"/>. It will switch EL to the same behaviour as it was before the server platform detection change.
2. Specify <persistence-unit name="xxx" transaction-type="RESOURCE_LOCAL"> in persistence.xml. In this case server platform will be WLS but resource local transactions are used. I am not sure that it will work though.
3. In theory, configuring Spring to use platform specific JTA transaction manager should also fix the problem.
All workarounds require some changes in customer's applications. I think it would be unacceptable to customers whose applications are broken after introducing the new version of EL.
I see the following solutions to this problem:
1. Rollback server platform auto detection code. I suppose that breaking backwards compatibility is a good reason for that.
2. Disable server platform auto detection for WLS only. It will fix it for WLS only.
3. Add a boolean system property eclipselink.server.autodetection which switches EL server platform auto detection. By default the value is false. It will make this feature 'experimental'. It will be up to customers enable it or not.
Please review the solutions above or offer your solution. We need to decide how to deal with this problem before EL 2.6.0. release.
On 30.1.2015 18:41, Dmitry Kornilov wrote:
In this particular case yes.
Back to the top