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

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

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

Back to the top