> On Dec 8, 2020, at 2:04 AM, Jean-Louis Monteiro <jlmonte...@tomitribe.com> > wrote: > > Hi all, > > Yesterday I worked on the EJB 3 failures related to naming context. > I realized we were failing on a couple of tests and I've been able to fix > them with configuration. > > But the last one was regarding the close operation. > Specification says > > 10.4.4. Container Provider Responsibility >> >> The container must ensure that the enterprise bean instances have only >> read access to their environment variables. 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. >> > > > Looking at the TCK, close() isn't considered as a method that modifies the > naming context. > > So I created ticket https://issues.apache.org/jira/browse/TOMEE-2935 > And fixed it with > https://github.com/apache/tomee/commit/13bf774f480c7cf841fafda6e027833fb22892d0 > > What do you think?
Playing devils advocate, the tricky one here is apps have the ability to create a new InitialContext and close is simply the counterpart of that. From that strict perspective, "new InitialContext" would also be illegal because it is not read-only. That said, if close was considered legal I'd expect it to only affect that exact InitialContext instance created by the app. That said, I've made an assumption this is in regards to javax.naming.InitialContext. If in fact the app is grabbing and closing any other context instance, it'd definitely be wrong. Do you have a source reference for the test? -David
smime.p7s
Description: S/MIME cryptographic signature
