RE: [eclipselink-users] contribution?

["Doug Clarke" <douglas.clarke@xxxxxxxxxx>]

Bryan,

I believe we want to fully embrace OSGi while still providing support for JavaSE/EE usage with JAR files. I believe this is possible based on our research efforts so far.

Many of the key people on this effort from the Oracle side are out or are working reduced hours through the holidays.

Shaun and I have started pulling together our OSGi ideas at: http://wiki.eclipse.org/EclipseLink/Development/OSGi

We need to continue to evolve this, review options, make some decisions and then move forward with our OSGi strategy for EclipseLink. We will schedule a call to discuss the open issues in January.

Doug

-----Original Message-----
From: eclipselink-users-bounces@xxxxxxxxxxx
[mailto:eclipselink-users-bounces@xxxxxxxxxxx]On Behalf Of Bryan Hunt
Sent: Wednesday, December 19, 2007 11:42 AM
To: EclipseLink User Discussions
Subject: Re: [eclipselink-users] contribution?


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