You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by "Tilmann Zäschke (Jira)" <ji...@apache.org> on 2023/05/11 19:06:00 UTC
[jira] [Updated] (JDO-827) Consider (re-)moving JNDI support
[ 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?
* 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.
> 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?
> * 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)