[jira] [Resolved] (ARIES-981) Ability to disable setting builders JVM singleton

["Guillaume Nodet (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARIES-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Nodet resolved ARIES-981.
-----------------------------------
       Resolution: Fixed
         Assignee: Guillaume Nodet
    Fix Version/s: jndi-core-1.1.0

> Ability to disable setting builders JVM singleton
> -------------------------------------------------
>
>                 Key: ARIES-981
>                 URL: https://issues.apache.org/jira/browse/ARIES-981
>             Project: Aries
>          Issue Type: Bug
>          Components: JNDI
>         Environment: Aries JNDI 1.0.0
>            Reporter: Mike Wilson
>            Assignee: Guillaume Nodet
>            Priority: Major
>             Fix For: jndi-core-1.1.0
>
>
> Aries JNDI's BundleActivator has the following code:
> {code}
> package org.apache.aries.jndi.startup;
> public class Activator
>   ...
>   public void start(BundleContext context)
>   {
>     ...
>     OSGiInitialContextFactoryBuilder builder = new OSGiInitialContextFactoryBuilder();
>     NamingManager.setInitialContextFactoryBuilder(builder);
>     ...
>   }
> {code}
> This code is setting javax.naming's singleton InitialContextFactoryBuilder globally for the JVM. This has the following problems:
> * An object from a dynamically loaded bundle is made available for any code executing in the JVM outside the OSGI container
> * Setting a global handler for the whole JVM is a bad idea for embedding scenarios and when running multiple OSGI containers in the same JVM
> * Javax.naming's InitialContextFactoryBuilder singleton is supposed to be settable only once. From NamingManager.setInitialContextFactoryBuilder docs:
> {quote}
> Once installed, the builder cannot be replaced. 
> {quote} and the javax.naming API doesn't support removing or changing this singleton. Respecting the API would mean that uninstalling Aries JNDI would leave the JVM with a dangling singleton.
> * To workaround the above, reflection tricks have been used in the code:
> {code}
> for (Field field : NamingManager.class.getDeclaredFields())
>   if (expectedType.equals(field.getType())) {
>     field.setAccessible(true);
>     field.set(null, null);
>   }
> {code}
> to hack into the JVM classes. This works in the Oracle JRE but is subject to fail in new JVM versions or JVMs of other brands.
> A better solution would be to only expose Aries JNDI's objects to bundles inside the respective OSGI container.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)