Hi Bryan,
I feel guilty about not having dug into your proposal--especially
after I promised I would get to it. But I think this is something we
should look at post-1.0. We're just working on dealing with all the
issues around moving the EclipseLink code base to OSGi and fixing bugs
at this point. You're talking about Equinox plugin stuff that none of
us understand yet. As we get some RCP experience we'll have a better
chance of offering an intelligent comments.
Not to say my next comment is not intelligent ;-), but I wanted to
point out that your PersistenceFactory makes use of the dreaded "Thread.currentThread().getContextClassLoader();" We don't make use of
buddy loading in EclipseLink and we are careful to use the right class
loader at all times. The context classloader isn't much use in a
"pure" OSGi environment. This is our goal--to run on any OSGi runtime
and enable platform specific features as add-ons. For example I'm
working on finishing up byte code weaving that is Equinox specific.
I'm also not sure I see the point in the
PersistenceConfigurationFactory. Why not put the config info in a file
instead of in code?
For now what I'd recommend is continuing to develop your code based
on EclipseLink M7 and up, which can be built using PDE. Or you can
grab night nightly builds to keep current with fixes. It would be
interesting to compare a "typical" RCP app built using EclipseLink OSGi
out of the box with one that uses your service/Equinox extension point
approach.
Shaun
Bryan Hunt wrote:
Shaun, I imagine you guys are quite busy, so I thought I'd
ping you real quick as a reminder to have a look at my proposal.
Bryan
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
--
Shaun Smith | Principal Product Manager, TopLink |
+1.905.502.3094
Oracle Fusion Middleware
110 Matheson Boulevard West, Suite 100
Mississauga, Ontario, Canada L5R 3P4
|