Re: [eclipselink-dev] Facilitating migration from Toplink / Toplink Esse

[Tom Ware <tom.ware@xxxxxxxxxx>]

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.

-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