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
-Toplink JPA applications work against Eclipselink without requiring
any additional artifacts
-Fits within current build infrastructure
-Conceptually not as "clean" approach as option 2 below
2. Ship as a separate jar.
-Conceptually cleaner approach
-Users would need additional artifacts to run Toplink applications
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)  . This one is easy to deal with by defining the property
Mitesh Meswani wrote:
Bill Shannon wrote:
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.
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.
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:
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.
* Add (say) org.eclipse.persistence.jpa.ToplinkPersistenceProvider
that extends org.eclipse.persistence.jpa.PersistenceProvider and
related PersistenceInitializationHelper (say)
* ToplinkPersistenceInitializationHelper would wire up a
JavaSECMPInitializer that would accept Toplink as provider
* Will above classes be part of default eclipselink
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
to know if that's the right place to put that functionality.
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
Does that work?
eclipselink-dev mailing list
Shaun Smith | Principal Product Manager
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