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