[
https://issues.apache.org/jira/browse/JDO-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilmann Zäschke updated JDO-827:
--------------------------------
Description:
The JDO API has two JNDI dependencies:
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
context)}} and
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context context,
ClassLoader loader)}}
The JNDI dependency complicates building and running the TCK (because of the
non-free nature of the implementation). It is also the only part of the API
that stops it being compatible with Android. The CI runs currently have all
tests disabled that depend on JNDI (TBD, how does it compile without the
classes???).
There are many options for simplifying this issue:
* Drop JNDI support? Is JNDI still used? Probably yes, see JDBC, JPA, EJB, JMS.
* Move the two methods into a separate JDOJNDIHelper. This would (probably)
allow us to more easily exclude it from builds when desired, for example using
Java 9 modules.
* Provide a dummy implementation of the JNDI classes. This would allow
compiling the API without problems (also on Android), but we would still need
to exclude it from tests.
* Switch to a free leightweight implementation, e.g.
https://github.com/h-thurow/Simple-JNDI
was:
The JDO API has two JNDI dependencies:
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
context)}} and
{{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context context,
ClassLoader loader)}}
The JNDI dependency complicates building and running the TCK (because of the
non-free nature of the implementation). It is also the only part of the API
that stops it being compatible with Android. The CI runs currently have all
tests disabled that depend on JNDI (TBD, how does it compile without the
classes???).
There are many options for simplifying this issue:
* Drop JNDI support? Is JNDI still used?
* Move the two methods into a separate JDOJNDIHelper. This would (probably)
allow us to more easily exclude it from builds when desired, for example using
Java 9 modules.
* Provide a dummy implementation of the JNDI classes. This would allow
compiling the API without problems (also on Android), but we would still need
to exclude it from tests.
* Switch to a free leightweight implementation, e.g.
https://github.com/h-thurow/Simple-JNDI
> Consider (re-)moving JNDI support
> ---------------------------------
>
> Key: JDO-827
> URL: https://issues.apache.org/jira/browse/JDO-827
> Project: JDO
> Issue Type: Improvement
> Components: api
> Affects Versions: JDO 3.2, JDO 3.2.1
> Reporter: Tilmann Zäschke
> Priority: Major
>
> The JDO API has two JNDI dependencies:
> {{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
> context)}} and
> {{JDOHelper.getPersistenceManagerFactory(String jndiLocation, Context
> context, ClassLoader loader)}}
> The JNDI dependency complicates building and running the TCK (because of the
> non-free nature of the implementation). It is also the only part of the API
> that stops it being compatible with Android. The CI runs currently have all
> tests disabled that depend on JNDI (TBD, how does it compile without the
> classes???).
> There are many options for simplifying this issue:
> * Drop JNDI support? Is JNDI still used? Probably yes, see JDBC, JPA, EJB,
> JMS.
> * Move the two methods into a separate JDOJNDIHelper. This would (probably)
> allow us to more easily exclude it from builds when desired, for example
> using Java 9 modules.
> * Provide a dummy implementation of the JNDI classes. This would allow
> compiling the API without problems (also on Android), but we would still need
> to exclude it from tests.
> * Switch to a free leightweight implementation, e.g.
> https://github.com/h-thurow/Simple-JNDI
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
