Bug 29727

Summary: JNDI env-entry not reload when context reloaded
Product: Tomcat 5 Reporter: robert engels <rengels>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P3    
Version: Nightly Build   
Target Milestone: ---   
Hardware: All   
OS: All   
Attachments: war file to demonstrate env-entry problem
If Environment entry is changed using admin app, the change is not visisble in JNDI. Patch to solve this problem

Description robert engels 2004-06-21 22:56:25 UTC
If environment entries are changed in web.xml, and the application context is 
restarted, the values in the JNDI context are the old values.

If the environment entries are changed via the Tomcat 'admin' interface, then 
the values provided to the context are correct.

The following code is can be used to check the environment:

        try {
            InitialContext ic = new InitialContext();
            NamingEnumeration enum = ic.listBindings("java:comp/env");

            while (enum.hasMore()) {
                Binding binding = (Binding) enum.next();
                jndi.setProperty(binding.getName(), "" + binding.getObject());
                System.out.println("jndi setting: " + binding.getName() + "=" 
+ binding.getObject());
            }
        } catch (NamingException e) {
            System.err.println("unable to read JNDI settings, " + e);
        }


The web.xml fragment looks as follows:

	<env-entry>
		<env-entry-name>DatabaseURL</env-entry-name>
		<env-entry-value>jdbc:hsqldb:hsql://localhost</env-entry-value>
		<env-entry-type>java.lang.String</env-entry-type>
	</env-entry>
Comment 1 Remy Maucherat 2004-06-22 08:09:44 UTC
The JNDI context is discarded between restarts, so I doubt that this is the
case. I recommend you investigate the issue further.
Comment 2 robert engels 2004-06-22 14:17:30 UTC
as I said, the application works correctly (i.e. the new value is picked up) 
when the environment value is changed via the Tomcat Admin interface, but does 
not work when the value is changed by manually editting the web.xml and 
stop/start the application.

So how can this be an application level problem?

The only thing I can thing of is that it is somehow related to a Classloader 
issue??? But I am not sure why it would work with the Admin interface then.


Comment 3 robert engels 2004-06-22 14:21:24 UTC
also, I found someone else reported the same issue on the mailing list...

http://archives.real-time.com/pipermail/tomcat-users/2003-March/103584.html
Comment 4 Yoav Shapira 2004-09-20 15:41:49 UTC
The code as posted can't be compiled: what's the "jndi" variable?

If you post a complete test case, i.e. a WAR file that I can drop into my 
Tomcat installation to reproduce your problem, I'll be glad to look at it.

In addition, can you please test 5.0.28, the latest stable Tomcat 5.0 release 
at the time of this writing?
Comment 5 robert engels 2004-09-20 19:46:34 UTC
Created attachment 12809 [details]
war file to demonstrate env-entry problem
Comment 6 robert engels 2004-09-20 19:51:05 UTC
I have posted the war file. I ran the test against 5.0.28 - no change, problem 
still exists. Thanks for looking into this.

To test:

install war in server

browse to <webserver>/<context>/listenv.jsp

-  the current value of the env-entry should be displayed

change the web.xml env-entry using some text editor.

reload the context, or allow tomcat to auto reload on change.

browse to <webserver>/<context>/listenv.jsp (refresh needs to be performed)

-  the OLD value is still displayed

change the env-entry using the tomcat 'admin' web interface. post changes.

browse to <webserver>/<context>/listenv.jsp (refresh needs to be performed)

-  the NEW value is still displayed
Comment 7 Igor 2004-10-30 06:03:50 UTC
Could you please consider the following modification of
org.apache.catalina.core.NamingContextListener class:

it was:

public void lifecycleEvent(LifecycleEvent event) {
...
            // Binding the naming context to the class loader
            if (container instanceof Context) {
                // Setting the context in read only mode
                ContextAccessController.setReadOnly(getName());
                try {
                    ContextBindings.bindClassLoader
                        (container, container,
                         ((Container)
container).getLoader().getClassLoader());
                } catch (NamingException e) {
                    log(sm.getString("naming.bindFailed", e));
                }
            }
...
}

I think, it should be:


public void lifecycleEvent(LifecycleEvent event) {
...
            // Binding the naming context to the class loader
            if (container instanceof Context) {



               namingResources.addPropertyChangeListener(this);



                // Setting the context in read only mode
                ContextAccessController.setReadOnly(getName());
                try {
                    ContextBindings.bindClassLoader
                        (container, container,
                         ((Container)
container).getLoader().getClassLoader());
                } catch (NamingException e) {
                    log(sm.getString("naming.bindFailed", e));
                }
            }
...
}


Thank you,
Igor
Comment 8 Igor 2004-11-01 14:53:13 UTC
Created attachment 13292 [details]
If Environment entry is changed using admin app, the change is not visisble in JNDI. Patch to solve this problem
Comment 9 Igor 2004-11-01 15:35:28 UTC
Sorry, this patch is wrong :-( Please do not apply it
Comment 10 robert engels 2004-11-01 16:05:11 UTC
The comments from Igor are not correct. It works ok if you change the variable
via the admin interface - it does not work if you manually change the web.xml,
and stop/restart the web application.
Comment 11 Yoav Shapira 2004-11-22 17:37:01 UTC
Updating version to 5.0.28.
Comment 12 Yoav Shapira 2005-03-26 04:23:05 UTC
The chances of this getting fixes in Tomcat 5.0.x are now slim.  Can either or
both of you test with 5.5.7 (or 5.5.9 which will be out in a couple of days) and
let us know if it works or not?  That would be great...
Comment 13 Igor 2005-07-22 07:32:11 UTC
I did a simple test with tomcat 5.5.9. Environment entries are reloaded when 
context is reloaded.

But if I change environment entry in admin application, it is not reloaded. To 
force application to see new entries user will have to reload context, which is 
dangerous operation.

It would be great if application would see new value after changing it in admin 
application too.

(In reply to comment #12)
> The chances of this getting fixes in Tomcat 5.0.x are now slim.  Can either or
> both of you test with 5.5.7 (or 5.5.9 which will be out in a couple of days) 
and
> let us know if it works or not?  That would be great...

Comment 14 Remy Maucherat 2005-07-22 07:59:47 UTC
That's pointless: accessing JNDI is costly, and is supposed to be read only in
the first place. As a result, webapps should be reading values, etc, in init,
and that's it.
Comment 15 robert engels 2005-07-22 08:18:10 UTC
My original bug, is that if the web.xml file is modified (via text editor, etc.)
while the context is running, and the context is restarted, the container is
supposed to detect this and load the new JNDI values.

This is according to the J2EE specification.

This does not occur in 5.0. I have not yet tested with the 5.5 release, but
based on the fact that nothing has been posted as a direct fix for this, I am
fairly certain the problem still exists.
Comment 16 Igor 2005-07-22 15:22:57 UTC
As a developer I want to have possiblity to change environment entries without 
restarting, reloading ... My application should work 24/7 and I do not want to 
restart or reload application because of I need to change only one parameter.

Environment entries are very convinient to store init parameters. And I do not 
want to change parameters too often. But it would be nice if I could change 
something in application parameters without restart.

I can "change" environment entries in admin application. What is this feature 
for, if it do not do anything, just changes value in admin?
Comment 17 Tim Funk 2005-07-22 16:09:49 UTC
This can be done via JMX. Assume you have a webapp called /myapp with a JNDI
environment string called i/need. It can be queried via the JMPXproxy in the
manager app. Here's the ouput example:

Name:
Catalina:type=Environment,resourcetype=Context,path=/myapp,host=localhost,name=i/need
modelerType: org.apache.catalina.mbeans.ContextEnvironmentMBean
className: org.apache.catalina.deploy.ContextEnvironment
name: i/need
override: false
type: java.lang.String
value: less cowbell

So your search URL would be (unescaped for readability ...)
http://localhost/manager/jmxproxy?qry=Catalina:type=Environment,resourcetype=Context,path=/myapp,host=localhost,name=i/need

And can be set via
http://localhost/manager/jmxproxy?set=Catalina:type=Environment,resourcetype=Context,path=/myapp,host=localhost,name=i/need&att=value&val=more+cowbell

More information:
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/manager-howto.html#What%20is%20JMX%20Proxy%20Servlet
Comment 18 robert engels 2005-07-22 16:18:19 UTC
Reopening bug. you cannot close as won't fix. your solution is not related to
this bug. This is a different bug, in that manual changes made to a web.xml
file, are not seen in the JNDI environment after a context restart. This is not
adhering to the J2EE specification.
Comment 19 Remy Maucherat 2005-07-22 16:24:41 UTC
Sure I can close the bug ;) This will not be fixed.
Comment 20 robert engels 2005-07-22 16:34:40 UTC
Sorry, but you are an idiot, or have very little reading comprehension skills.

This bug needs to be fixed, it is not J2EE compliant. You do not need to fix the
request in comment #13, that changes are visible in the JNDI context without a
reload when changes are made via the admin interface. There is not in J2EE that
states that a container must update the JNDI context in real-time, but not sure
that the feature wouldn't be helpful as Igor has pointed out.
Comment 21 Remy Maucherat 2005-07-22 16:45:54 UTC
(In reply to comment #20)
> Sorry, but you are an idiot

That sounds good to me :)

To translate since you apparently have very little general comprehension skills,
this minor issue will not be fixed in the 5.0.x branch.
Comment 22 robert engels 2005-07-22 16:59:30 UTC
How is it a minor issue? Do you run any large, multiple server, sites at all? It
is fairly common to update deployed application by copying new web.xml files to
the deployment directories, and then use the Tomcat weburl to restart the context.
Comment 23 robert engels 2006-09-19 17:53:10 UTC
Why is this bug not moved to the 5.5 branch then?

The J2EE specification states that the JNDI variables for an application are
reloaded during a CONTEXT RESTART. This is the only way for init() methods in a
servlet to retrieve any changed values.

This bug is NOT related to Igor's comments where he wants JNDI changes to be
visible as they are made.

For what it is worth, I tested this behavior with Jetty and it works as expected.
Comment 24 Mark Thomas 2006-09-20 01:52:52 UTC
Tested against 5.5.x and is still present. I am working on a fix...

Note, I am only considering the original bug report.
Comment 25 Mark Thomas 2006-09-21 23:58:00 UTC
This is fixed in svn and will be in 5.5.21 onwards.