Skip to main content

[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

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
   -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) [1] [2]. This one is easy to deal with by defining the property eclipselink.allow-zero-id=true.



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 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.


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

Oracle <>
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 <> Oracle is committed to developing practices and products that help protect the environment

eclipselink-dev mailing list

Back to the top