https://issues.apache.org/bugzilla/show_bug.cgi?id=51744
--- Comment #14 from Leonid Mikhailov <lmikhai...@esri.com> 2011-12-01 23:17:40 UTC --- (In reply to comment #13) > The correct exception is now thrown and the option to control whether or not > an > exception is thrown has been added to the StandardContext. > > Both of these changes have been made to trunk and 7.0.x and will be included > in > 7.0.23 onwards. Mark, I just installed 7.0.23 and I still see "Context is read only" exception thrown. In your previous message you mentioned: > To quote from section EE.5.3.4 of the Java EE spec > <quote> > The container must ensure that the application component instances have only > read access to their naming context. The container must throw the > javax.naming.OperationNotSupportedException from all the methods of the > javax.naming.Context interface that modify the environment naming context and > its subcontexts. > </quote> > > I would argue that the close() method is a method that "modifies the > environment naming context" and therefore an exception should be thrown here. I hoped to avoid an argument but... I believe you are not interpreting the spec correctly. Here is a recommendation from a tutorial (http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/close.html) explaining how one is supposed to work with Contexts: "Normal garbage collection takes care of removing Context instances when they are no longer in use. Connections used by Context instances being garbage collected will be closed automatically. Therefore, you do not need to explicitly close connections. Network connections, however, are limited resources and for certain programs, you might want to have control over their proliferation and usage." And here is a promoted usage pattern: // Create initial context DirContext ctx = new InitialDirContext(env); // Get a copy of the same context Context ctx2 = (Context)ctx.lookup(""); // Get a child context Context ctx3 = (Context) ctx.lookup("ou=NewHires"); // do something useful with ctx, ctx2, ctx3 // Close the contexts when we're done ctx.close(); ctx2.close(); ctx3.close(); Closing a context has nothing to do with modifying it - you are just telling the system that you are done with a resource and it can be safely released at this time. Modifying a context means adding and/or deleting something from it. I have written a sample application that works as described above with no logged exceptions in GlassFish and in all Tomcat versions prior to 7.0.22. I can send it to you if you like. I don't believe the current implementation is correct. No exceptions should be logged by default. Regards, Leon -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
