tracker issue : CF-4190478

select a category, or use search below
(searches all categories and all time range)

Server could not access global JNDI ressources

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/ThirdParty

Reporter/Name(from Bugbase): Andre Münz / Andre Münz (Andre Münz)

Created: 09/19/2016

Components: Web Container (Tomcat)

Versions: 2016

Failure Type: Crash

Found In Build/Fixed In Build: CF2016_Update1 /

Priority/Frequency: Normal / All users will encounter

Locale/System: ALL / Linux

Vote Count: 0

Problem Description:
We are using ColdFusion 9 (Stage Beta and Production) and ColdFusion 2016 (Stage Development and Alpha)
We deploy the Server as a J2EE container in a Tomcat 7 environment (for ColdFusion 9) and Tomcat 8 (for ColdFusion 2016)
We use global JNDI ressources, defined in Tomcat (<GlobalNamingResources>-section) to store parameter, paths and passwords to develop stage-indepentent ColdFusion code

Since a new Tomcat8 release (8.0.37) it is not possible to get access to the global JNDI resources from ColdFusion server.
Every try to read a JNDI ressource returns "undefined" (or more correct NULL)
ColdFusion fails to has access on global JNDI ressources (plz habe a look on the new "feature" of Tomcats ResourceLinkFactory)

Steps to Reproduce:

Deploying a pure Java application on Tomcat 8.0.37 returns the correct values.
Deploying a ColdFusion 9 or 2016 on Tomcat 8.0.37 returns NULL on accessing a global ressource and the correct value on acessing a local context ("my/local/test" as defined in context.xml)
Downgrading to Tomcat 8.0.35 returns the correct results on both ColdFusion versions

Actual Result:

with Tomcat 8.0.37: undefined (NULL)

Expected Result: 

with Tomcat 8.0.35: JohnDoe (as defined in <GlobalNamingResources> of server.xml)

Any Workarounds:

downgrading Tomcat to version 8.0.35

compiling a modified Tomcat 8.0.37 without the following lines in apache-tomcat-8.0.37-src/java/org/apache/naming/factory/

... //line 142-144

    if (!validateGlobalResourceAccess(globalName)) {
        return null;


----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	4190478

External Customer Info:
External Company:  
External Customer Name: Andre Münz
External Customer Email:  
External Test Config: server.xml (within Tomcat)



    <Environment name="my/secret/password" value="JohnDoe" type="java.lang.String"/>


context.xml (/META-INF/context.xml)


<?xml version="1.0" encoding="UTF-8"?>


    <Environment name="my/local/test" value="local test" type="java.lang.String" override="false"/>

    <ResourceLink name="my/secret/password" global="my/secret/password" type="java.lang.String" />




component {

    public jndiReader function init() {

        variables.ctx = createobject("java","javax.naming.InitialContext");

        variables.envCtx  = ctx.lookup("java:comp/env/");


        return this;



    public any function read(required string keyName) {


            return envCtx.lookup(arguments.keyName);


        catch(any e){

            throw(type = "Application", message = "Error: Could not read service key. Maybe the key is not bind via JNDI.");




By the way, I wrote a Java component too, which I place outside the ColdFusion server into the lib-folder of our Tomcat


package my.test.wrapper;

import javax.naming.Context;

import javax.naming.InitialContext;

import javax.naming.NamingException;


 * Created by amz

 * on 2016/Sep/14 14:55.


public class EnvironmentJndiWrapper {

    public EnvironmentJndiWrapper() throws NamingException {}

    public String lookupKey(String key) throws NamingException {

        InitialContext initCtx = new InitialContext();

        Context rootCtx = (Context) initCtx.lookup("java:comp/env");

        String value = (String) rootCtx.lookup(key);

        return value;



ColdFusion Template



    try {

        //access via instanciating existing Java components

        ctx = createobject("java", "javax.naming.InitialContext");

        envCtx = ctx.lookup(JavaCast("string", "java:comp/env"));

        test = envCtx.lookup("my/secret/password");



    catch(any e){



    try {

        //access via JNDI wrapper (see Java component above)

        ctx = createobject("java", "my.test.wrapper.EnvironmentJndiWrapper");

        test = ctx.lookupKey(JavaCast("String", "my/secret/password"));



    catch(any e){






It does not depends on Platform. It works neither on Linux nor on Windows
Comment by External U.
1783 | September 19, 2016 03:10:32 AM GMT
The bug is not only part of CF2016_Update1, it is more generic and I reproduce it also with CF9.
Comment by External U.
1784 | September 19, 2016 03:13:27 AM GMT
Is there a response from Adobe ?
Comment by External U.
1785 | September 27, 2016 07:13:21 AM GMT
We shall get the same verified , ASAP !
Comment by Suresh J.
1786 | September 28, 2016 05:19:57 AM GMT
This is an issue with tomcat and they have fixed it. It will be available as part of next tomcat release.
Comment by Chinoy G.
1787 | October 04, 2016 03:34:50 AM GMT
Yes, you are right Chinoy Gupta, it depends on a source code changing of the tomcat, coming with 8.0.37 (and 8.5.5 I think). Here are the new lines of the which are responsible for this behaviour I noticed above. // apache-tomcat-8.0.37-src/java/org/apache/naming/factory/ // Confirm that the current web application is currently configured // to access the specified global resource if (!validateGlobalResourceAccess(globalName)) { return null; } but... This means, that ColdFusion is NOT configured to access global resources (and there is - in my opinion - no way to configure it without rebulding the ColdFusion distribution). A Java web application deployed on Tomcat IS configured to accesss these resources by default. So ColdFusion does not act like a plain Java application.
Comment by External U.
1788 | October 04, 2016 04:10:08 AM GMT
The difference in behavior is due to different classloaders. When you run java application, it tries to access the resource through default classloader. But in case of CF, it is custom classloader.
Comment by Chinoy G.
1789 | October 04, 2016 04:42:45 AM GMT
Fixed with Tomcat Version 8.0.38. THX
Comment by External U.
1790 | October 27, 2016 02:58:33 AM GMT