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"
(→Issues) |
(→Issues) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 3: | Line 3: | ||
: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|Shaun Smith]] 12:53, 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|Shaun Smith]] 12:53, 9 January 2008 (EST) |
| + | |||
| + | ::: I did not mean we can't legally change the javax jars, I meant we do not control these files, they are defined by the application server (OC4J, Glassfish, JBoss, WAS, WLS), this would seem to prevent us from running in these are any other of our typical users environment? [[User:James.sutherland.oracle.com|James.sutherland.oracle.com]] 15:34, 9 January 2008 (EST) | ||
| + | |||
| + | :::: The idea is that the only time the modified javax.persistence classes would be used is in an OSGi environment. In this case, EclipseLink would obtain the spec classes from an OSGi bundle provided by the EclipseLink project. If EclipseLink is used in a Java SE or EE environment then the spec classes would be found on the classpath--possibly provided by an app server. | ||
Latest revision as of 13:29, 14 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. Shaun Smith 12:53, 9 January 2008 (EST)
- I did not mean we can't legally change the javax jars, I meant we do not control these files, they are defined by the application server (OC4J, Glassfish, JBoss, WAS, WLS), this would seem to prevent us from running in these are any other of our typical users environment? James.sutherland.oracle.com 15:34, 9 January 2008 (EST)
- The idea is that the only time the modified javax.persistence classes would be used is in an OSGi environment. In this case, EclipseLink would obtain the spec classes from an OSGi bundle provided by the EclipseLink project. If EclipseLink is used in a Java SE or EE environment then the spec classes would be found on the classpath--possibly provided by an app server.