Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] contribution?


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.


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?


eclipselink-users mailing list

Back to the top