Hi Bryan,
Like Doug said in his email we'll have to get on the phone and have
an open meeting on this. But your comments are similar to those of
Peter Kriens, OSGi technical director. I've had a couple of
conversation with him recently about our OSGi initiative. He also
advocated a service based approach with a generic JPA service and
provider specific services so a bundle could express a requirement for,
say, EclipseLink if they were using EclipseLink extensions. Makes
sense. I also discussed with him issues around class loading and he
suggested looking at some blog posts of his on Hibernate which I linked
to from the wiki [1].
He was also very clear that OSGi is looking to address classloader
issues like we have and like those coming from the AOP community. We
can certainly feed the results of our experiences into OSGi. Right now
we can "hack" around things with Equinox buddy classloader policies but
this isn't portable and it's hard to say you support OSGi when you only
work in one container. :-)
So, contrary to what I'd said before, I think it would be useful if
you were to obtain permission to contribute your code and attach it to
the OSGi bug [2]. It will be way easier to discuss the issues and
evaluate options if the code is generally available for the EclipseLink
community.
Shaun
[1] http://wiki.eclipse.org/EclipseLink/Development/OSGi
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=210979
Bryan Hunt wrote:
Shaun,
Yes, the OSGi service approach is primarily designed for things that
come and go which would probably be a problem for JPA. This is not to
say that services shouldn't be used for JPA. Eclipse itself uses
services for things that would be a problem if the service provider
were disabled. For example, when you call
Platform.getPreferenceService(), you are really getting an OSGi
service. If you were to hot-plug a new preferences service, your
client code could easily fail if you were keeping a handle to the
preference service.
My approach for making the EntityManagerFactory available as a service
doesn't really solve a technical problem. It does make JPA more OSGi
friendly. It really depends on whether EclipseLink wants to simply be
OSGi tolerant, or to fully embrace OSGi. Probably the more interesting
thing I could contribute is my extension point for declaring entities
and building the persistence.xml on-the-fly. Now, this does solve a
technical problem of how to create an extensible framework that uses
entities.
If this is not interesting, I can simply layer my existing code on top
of EclipseLink for my own use just as I have done with Hibernate.
Bryan
On Dec 12, 2007, at 11:16 AM, SHAUN SMITH wrote:
Hi Bryan,
What is the level of interest in the
contribution of my work on
integrating JPA into Eclipse? I've started down the path of getting
permission to contribute which requires a proposal, several approvals,
and sign-off by two different review boards. I just want to make sure
there's serious interest in my contribution before I do all this work
to get it approved.
I agree. If you have to go through a bunch of work to provide the
contribution we should probably figure out what is the right way
forward first. So far I'm satisfied with packaging of EclipseLink as a
set of bundles and using the JPA "as is". That is, bootstrapping
using the SPI Persistence.createEntityManagerFactory(...). Your
service based approach looks interesting but what problem does it solve
that this naive approach doesn't? Can you elaborate on what drove you
this direction?
What should happen if the implementation
bundle is stopped and there
are active EntityManagers?
It seems like an OSGi service approach is suitable for things that can
come and go--like a printing service or logging service. I wouldn't
expect a JPA implementation to be something that could come and go?
Shaun
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
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
|