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>
The JNDI context is discarded between restarts, so I doubt that this is the case. I recommend you investigate the issue further.
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.
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
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?
Created attachment 12809 [details] war file to demonstrate env-entry problem
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
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
Created attachment 13292 [details] If Environment entry is changed using admin app, the change is not visisble in JNDI. Patch to solve this problem
Sorry, this patch is wrong :-( Please do not apply it
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.
Updating version to 5.0.28.
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...
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...
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.
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.
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?
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
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.
Sure I can close the bug ;) This will not be fixed.
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.
(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.
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.
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.
Tested against 5.5.x and is still present. I am working on a fix... Note, I am only considering the original bug report.
This is fixed in svn and will be in 5.5.21 onwards.