Bug 1086129 - Changing the JNDI bound values in the naming subsystem requires reload.
Summary: Changing the JNDI bound values in the naming subsystem requires reload.
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Naming
Version: 6.1.0
Hardware: All
OS: All
Target Milestone: ---
: ---
Assignee: Jay SenSharma
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2014-04-10 07:46 UTC by Jay SenSharma
Modified: 2018-12-05 18:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-04-14 05:35:32 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-3239 0 Major Resolved Changing the JNDI bound values in the naming subsystem requires reload. 2016-11-23 16:16:42 UTC

Description Jay SenSharma 2014-04-10 07:46:46 UTC
Description of problem:
    Changing the values which are binded in the naming subsystem shows "reload-required", which it ideally should not. The JNDI naming should follow the "rebind" feature of InitialContext. The values should be rebinded in the JNDI.

    Ideally the JNDI value should not have required the reload and in the runtime only the JNDI value should have changed.

Version-Release number of selected component (if applicable):

How reproducible:
Steps to Reproduce:

1. Bind a simple object in the JNDI like following:

[standalone@localhost:9999 /] /subsystem=naming/binding=java\:jboss\/exported\/test/:add(binding-type=simple,value=100,type=int)
{"outcome" => "success"}

2. Change the value of the jndi binding as following:

[standalone@localhost:9999 /] /subsystem=naming/binding=java\:jboss\/exported\/test/:write-attribute(name=value,value="500")
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"

3. Now using a simple JNDI lookup code check the value of the JNDI it will still show "100". Like use the following JSP code to do a jndi lookup.

<%@page import="java.util.*,javax.naming.*" %>
       String jndiName = "java:jboss/exported/test";
       int data =0;
            Context ic = new InitialContext();
            System.out.println("\n\tAbout to look up jndi name " + jndiName);
            Object obj = ic.lookup(jndiName);
            System.out.println("lookup returned " + obj);
            data= (Integer) obj;
            System.out.println("\n\tGot the Data: " + data);
     catch(Exception e)
             System.out.println("******* Inside catch "+e);
     out.println("<h1>Got the Data: " + data);

    However the value is persisted in the XML configuration as following:

    [standalone@localhost:9999 /] /subsystem=naming/binding=java\:jboss\/exported\/test/:read-attribute(name=value)
        "outcome" => "success",
        "result" => "500",
        "response-headers" => {"process-state" => "reload-required"}

    It can be noticed that in the JNDI which was bound as 100 with JNDI name as "java:jboss/exported/test", then later when tried changing the value of this JNDI bindng from "100" to "500" and it is noticed that even after the "write-attribute" operation the runtime model object value was still 100 but the changes were persisted in the XML configuration as following:

            <subsystem xmlns="urn:jboss:domain:naming:1.3">
                    <simple name="java:jboss/exported/test" value="500" type="int"/>

Actual results:
- The XML configuration gets updated but the object which is bound in the JNDI  does not get changed in the Runtime. 

Expected results:
- The JNDI bound value change should have reflected without the need of reload.

Additional info:
- As the InitialContext has a method rebind(Name name, Object obj) Binds a name to an object, overwriting any existing binding similarly the above CLI command also should have worked in runtime. [1]

[1] http://docs.oracle.com/javase/6/docs/api/javax/naming/InitialContext.html#rebind(javax.naming.Name, java.lang.Object)

Comment 3 JBoss JIRA Server 2015-01-20 07:36:16 UTC
Eduardo Martins <emartins.redhat> updated the status of jira WFLY-3239 to Resolved

Comment 4 JBoss JIRA Server 2016-04-26 23:04:41 UTC
Stuart Douglas <stuart.w.douglas> updated the status of jira WFLY-3239 to Reopened

Note You need to log in before you can comment on or make changes to this bug.