Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:EclipseLink/Development/OSGi"
(New page: == Issues == :Correct me if I'm wrong, but we cannot change javax classes? In general it seems like this work will seriously hurt our portablity, and seems like a very bad idea? ~~~~) |
(→Issues) |
||
| Line 2: | Line 2: | ||
:Correct me if I'm wrong, but we cannot change javax classes? In general it seems like this work will seriously hurt our portablity, and seems like a very bad idea? [[User:James.sutherland.oracle.com|James.sutherland.oracle.com]] 08:41, 9 January 2008 (EST) | :Correct me if I'm wrong, but we cannot change javax classes? In general it seems like this work will seriously hurt our portablity, and seems like a very bad idea? [[User:James.sutherland.oracle.com|James.sutherland.oracle.com]] 08:41, 9 January 2008 (EST) | ||
| + | |||
| + | Actually, we can change the javax classes. AFAIK the CDDL license permits modifications. However, the goal of the modification we're suggesting is to make the provider discovery code pluggable to enable the use of OSGi services. By default, it will work as it does now and simply try to use the current thread class loader to find providers through META-INF\services\javax.persistence.spi.PersistenceProvider. This change will not affect portability as EclipseLink will not rely on these modifications in any way. It will simply provide a means to find the EclipseLink JPA provider in an OSGi environment. [[User:Shaun.smith.oracle.com|ShaunSmith]] 12:53, 9 January 2008 (EST) | ||
Revision as of 13:53, 9 January 2008
Issues
- Correct me if I'm wrong, but we cannot change javax classes? In general it seems like this work will seriously hurt our portablity, and seems like a very bad idea? James.sutherland.oracle.com 08:41, 9 January 2008 (EST)
Actually, we can change the javax classes. AFAIK the CDDL license permits modifications. However, the goal of the modification we're suggesting is to make the provider discovery code pluggable to enable the use of OSGi services. By default, it will work as it does now and simply try to use the current thread class loader to find providers through META-INF\services\javax.persistence.spi.PersistenceProvider. This change will not affect portability as EclipseLink will not rely on these modifications in any way. It will simply provide a means to find the EclipseLink JPA provider in an OSGi environment. ShaunSmith 12:53, 9 January 2008 (EST)