Last time I tried was a long time ago, and my attempt bounced.
Because the Tomcat JNDI registry is primarily used for configuration information, the ability to add/update entries could potentially cause trouble, so to be conservative, I'd avoid doing so. However, one thing you might do is see if you can add elements to the "java:comp/env" directory tree. It's possible that that section is protected, since that's where the critical data is, while other trees might be safe.
I would, however, check the JEE spec and see what (if anything) it has to say on applications updating JNDI. In the final analysis, what you can do versus what you should do is critical. People used to alter incoming parameters from Httpservlet requests, but that wasn't supported by the spec and one day Tomcat started adhering more closely to the spec, the offending apps broke, and the "clever" people had no one to blame but themselves. Same thing applies to people who write data files to their WARs, only in that particular case, I can break existing apps just by changing the Tomcat deployment configuration.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.
posted 6 years ago
Thanks Tim. By the way, nicely said about can-do vs should-do.
I tried binding the object to java:comp/env tree and now Tomcat woke and complained about "Context is read-only"
Out of curiosity, when you do not specify JNDI tree location and just do new IntialContext() and then bind("test",new String("TESTJNDI"));
which location in directory tree is the object bound to?