Tom Ware wrote:
I am not
fond of having a default version of EclipseLink ever allow itself to be
selected when the user has specifically requested TopLink Essentials in
their persistence.xml.
Bill's suggestion of some kind of an add-on is more palatable to me if
we decide we want to have a way of having EclipseLink select itself
in place of Essentials.
I think I am not clear about what that means in terms of
implementation. Can we explore that a bit. Here is my understanding if
we go that route:
- Add (say) org.eclipse.persistence.jpa.ToplinkPersistenceProvider
that extends org.eclipse.persistence.jpa.PersistenceProvider and
related PersistenceInitializationHelper (say)
ToplinkPersistenceInitializationHelper
- ToplinkPersistenceInitializationHelper would wire up a subclass
of JavaSECMPInitializer that would accept Toplink as provider
- Will above classes be part of default eclipselink distribution as
part of eclipselink.jar and org.eclipse.persistence.jpa.jar?
Thanks,
Mitesh
-Tom
Mitesh Meswani wrote:
As I mentioned below, EclipseLink would
accept Essentials provider class only if Essentials is not available in
classpath. This assumes that if a user intended to run with Essentials,
he would have made Essentials visible to application else he is trying
to migrate from an environment where he relied on Essentials into an
environment that only has EclipseLink.
This is a kludge and I personally dislike it. However, this is the only
way I see to facilitate users migrating from an environment that had
Essentials to EclipseLink without them manually updating their app.
Thanks,
Mitesh
Gordon Yorke wrote:
This is an error case as the user has
explicitly asked for Essentials and EclipseLink will not care if
Essentials is available or not. If EclipseLink were to accept the
Essentials provider how would a user run Essentials applications in V3?
--Gordon
Mitesh Meswani wrote:
Hi Gordon,
Overriding provider is for the case where user has explicitly specified
provider as Toplink but running in an environment where only
EclipseLink is available.
Thanks,
Mitesh
Gordon Yorke wrote:
There should be no need to override the
provider as the provider is only specified if a user wants a specific
provider as by default there is no provider specified. Using the
essentials properties as eclipselink properties would be a good idea.
--Gordon
Tom Ware wrote:
I like part 1 of the proposal.
I do not think that EclipseLink itself should allow itself to be
selected as the JPA provider when the user has specifically chosen
TopLink Essentials. To me, if a user requests a specific JPA provider
another provider should not allow itself to be selected. Perhaps this
is something that should be done within GlassFish rather than within
EclipseLink.
-Tom
Mitesh Meswani wrote:
*Background*
Currently, an app using Toplink / Toplink Essentials as JPA provider
(and not using any of provider specific features in code), will still
need to be manually modified by user to change persistence.xml for
property names from toplink.* to eclipselink.* and provider name from
oracle.toplink.*.EntityManagerFactoryProvider to
org.eclipse.persistence.jpa.PersistenceProvider. We know that
EclipseLink has a migration tool that helps user with this. However,
using the tool would require manual steps from user. It might not be
possible/convenient for many users to change their packaged application
(like .ear and .war) for this. This issue came up during discussion
about upgrade from GlassFish V2 to V3
*Proposal
*1. We translate the property names and provider during deploy. This
would help ease migration from Toplink to EclipseLink for majority of
JPA users who would mainly be using toplink.jdbc.* properties in their
persistence.xml.
2. We accept oracle.toplink.*.EntityManagerFactoryProvider as a
supported class name
To be more specific, for 1 above, we enhance
EntityManagerSetupImpl#deploy() to translate old toplink properties in
addition to translation that it is doing now. For 2 above, we enhance
JPAInitializer.isPersistenceProviderSupported(String className) to
accept oracle.toplink.*.EntityManagerFactoryProvider as a supported
provider. To facilitate the use case where a user explicitly wants to
use Toplink, we can try to be clever in accpeting toplink as a
supported provider only if Toplink is not found in classpath.
I can work on implementing this. Please reply with your
thoughts/comments.
Thanks,
Mitesh
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
|