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

[Mitesh Meswani <Mitesh.Meswani@xxxxxxx>]

Forwarding to dev list on behalf of Bill......

-------- Original Message --------
Subject: 	Re: [eclipselink-dev] Facilitating migration from Toplink / 
Toplink Essentials to EclipseLink for pure JPA applications
Date: 	Thu, 27 Aug 2009 10:11:09 -0700
From: 	Bill Shannon <Bill.Shannon@xxxxxxx>
To: 	Tom Ware <tom.ware@xxxxxxxxxx>
CC: 	Dev mailing list for Eclipse Persistence Services 
<eclipselink-dev@xxxxxxxxxxx>, Edward Bratt <Edward.Bratt@xxxxxxx>, 
Jerome Dochez <Jerome.Dochez@xxxxxxx>, Mitesh Meswani 
<Mitesh.Meswani@xxxxxxx>
References: 	<4A95D376.8090408@xxxxxxx> <4A96A415.2050103@xxxxxxxxxx>



(I probably won't be able to post to eclipselink-dev, can someone
please forward this?)

How about if the EclipseLink project were to produce a "fake"
TopLink provider that simply layered on / delegated to the
EclipseLink provider while providing this level of compatibility.
That wold allow people who wanted the real TopLink provider to
remove the fake version and install the real version.  It would
also allow the EclipseLink module to remain relatively "pure".

Since EclipseLink is the successor to TopLink, it seems appropriate
for this compatibility package to come from the EclipseLink project.


Tom Ware wrote on 8/27/09 8:19 AM:
> 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