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
--
<oracle_sig_logo.gif> Shaun Smith | Principal Product Manager, TopLink | +1.905.502.3094
Oracle Fusion Middleware
110 Matheson Boulevard West, Suite 100
Mississauga, Ontario, Canada L5R 3P4
