[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-dev] Facilitating migration from Toplink / Toplink Essentials to EclipseLink for pure JPA applications
|
If we decide to go that way, I think you have the gist of what would happen.
The thing we would have to figure out is distribution.
- I think we would want a class that overrides the request to use Essentials as
the persistence provider to be somewhere where an EclipseLink user would not get
it by default. (either in a separate jar, distributed with a separate services
file, or enabled by some kind of property)
- We would still have to discuss whether this would be distributed as part of
GlassFish or as part of EclipseLink
-Tom
Mitesh Meswani wrote:
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
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
