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

[Douglas Clarke <DOUGLAS.CLARKE@xxxxxxxxxx>]

Mitesh,

I do not believe it makes sense for the EclipseLink project to host alternate JPA providers to facilitate compatibility. If a user placed TopLink Essentials and EclipseLink JPA on their classpath they should be able to choose their provider.

If GlassFish has a requirement to transparently support TopLink Essentials defined persistence units when only EclipseLink is on the classpath we can definitely help you implement such functionality within GlassFish. Assuming developers only made use of advertised JPA API and extensions you would need a solution that addresses:

1. The TLE persistence provider being specified
2. Translation of persistence unit properties: toplink.* -> eclipselink.*
3. Translation of query hints: toplink.* -> eclipselink.*
4. Differences in behaviour and associated new configuration flags (as discussed earlier on this thread).

After dealing directly with Oracle's customers who used TopLink with TLE and now are upgrading to TopLink with EclipseLink the migration process is very quick and easy. Doing the upgrade is also useful as it makes it clear to the customers that they are using a different provider and it comes with additional capabilities. I would recommend the migration solution versus the transparent backwards compatibility.

If you do require the transparent support we should then discuss what infrastructure within the EclipseLink project is required to facilitate the development of your provider 'wrapper'. Some pluggable components to translate persistence unit properties and query hints may make sense.

Cheers,

Doug

-----Original Message-----
From: Mitesh Meswani [mailto:Mitesh.Meswani@xxxxxxx]
Sent: Wednesday, September 02, 2009 3:02 PM
To: Dev mailing list for Eclipse Persistence Services
Cc: Edward Bratt; Jerome Dochez; Bill Shannon
Subject: Re: [eclipselink-dev] Facilitating migration from Toplink /
Toplink Essentials to EclipseLink for pure JPA applications


Thanks Shaun for bringing this up. I will add this to scope of the work. 
Do we have list of such changes that we can refer against?

 From discussions so far, the only outstanding issue is about packaging. 
We have following options on table from current discussion. Can you 
please vote with the option you prefer.

1. Ship this as part of eclipselink.jar and 
org.eclipse.persistence.jpa.jar and enable the compatibility mode with a 
system property
    Pros :
    -Toplink JPA applications work against Eclipselink without requiring 
any additional artifacts
    -Fits within current build infrastructure
    Cons:
    -Conceptually not as "clean" approach as option 2 below

2. Ship as a separate jar.
    Pros:
    -Conceptually cleaner approach
    Cons:
    -Users would need additional artifacts to run Toplink applications

Thanks,
Mitesh
      
Shaun Smith wrote:
> Behavioral difference between TopLink Essentials and EclipseLink have 
> to be dealt with in this "auto migration" initiative.  For example, 
> the handling of zero id values for primitive data types (i.e, int, 
> long) [1] [2].  This one is easy to deal with by defining the property 
> eclipselink.allow-zero-id=true.
>
>    Shaun
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=277804
> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=278216
>
> Mitesh Meswani wrote:
>> Bill Shannon wrote:
>>> Mitesh Meswani wrote on 08/28/09 10:28:
>>>> 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?
>>>
>>> I was thinking that the class would have the exact class name of the
>>> TopLink provider - oracle.toplink.essentials.whatever.  No magic would
>>> be needed to translate the class name in the application to the actual
>>> class being used.  Ideally, that new class would be the one that would
>>> translate the property names, but I don't know how this all fits 
>>> together
>>> to know if that's the right place to put that functionality.
>> That would be cleanest. However, AFAIK, the properties are processed 
>> at place in code that is not aware of how it is being invoked. We 
>> should look into having this implemented as above once we get into 
>> code to implement this.
>>
>> Thanks,
>> Mitesh
>>
>>>
>>> These new classes would be packaged in a separate jar file, a separate
>>> OSGi module, that depends on the EclipseLink module.  A user could
>>> uninstall that module and install the real TopLink module if they
>>> wanted to.
>>>
>>> Does that work?
>>>
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>
> -- 
> Oracle <http://www.oracle.com>
> Shaun Smith | Principal Product Manager
> Phone: +19055023094
> Oracle Server Technologies, Oracle TopLink
> ORACLE Canada | 110 Matheson Boulevard West, Suite 100, Mississauga, 
> Ontario | L5R 3P4
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
> developing practices and products that help protect the environment
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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