[ 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)